unsubsriebMSN 8: advanced junk mail protection and 2 months FREE*
On Fri, Jan 10, 2003 at 07:15:34AM +, Peter Mount wrote:
> On Thu, 9 Jan 2003, Peter Eisentraut wrote:
>
> > Tom Lane writes:
> >
> > > The case I find interesting is where you're using plain "\e" to
> > > re-edit a query interactively. If this query never gets into the
> > > history buffer
On Thu, 9 Jan 2003, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > The case I find interesting is where you're using plain "\e" to
> > re-edit a query interactively. If this query never gets into the
> > history buffer then you're lost: you won't be able to pull it back
> > for re-editing a se
Neil Conway <[EMAIL PROTECTED]> writes:
> On Thu, 2003-01-09 at 16:53, Tom Lane wrote:
>> Yeah, that was on my to-fix list also.
> Heh, I too was planning to implement this. Would you like to take a
> crack it at, or should I?
Go for it...
regards, tom lane
-
On Thu, 2003-01-09 at 16:53, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I notice that you can't explain stored plans, i.e., EXPLAIN EXECUTE.
> > Might be handy to have.
>
> Yeah, that was on my to-fix list also.
Heh, I too was planning to implement this. Would you like to
On Thu, 2003-01-09 at 22:48, Christopher Kings-Lynne wrote:
> With prepared statements being all well and good, how do I know if the query
> has not yet been prepared in the backend? Or is this simply a situation
> where I can't win?
Try the EXECUTE; if it fails, run the PREPARE and then rerun th
I guess I should just use a stored procedure...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher
> Kings-Lynne
> Sent: Friday, 10 January 2003 11:48 AM
> To: Hackers
> Subject: [HACKERS] Prepared statements question
>
>
> Hi,
>
>
Hi,
With prepared statements being all well and good, how do I know if the query
has not yet been prepared in the backend? Or is this simply a situation
where I can't win?
eg. Say I have a web page that does a humungous query. I would like to have
that query prepared, say, for speed. However,
Change it - but just put it in the release notes :)
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane
> Sent: Friday, 10 January 2003 1:10 AM
> To: Jan Wieck; Peter Eisentraut
> Cc: PostgreSQL HACKERS
> Subject: Re: [HACKERS] Dollar in
Bruce Momjian wrote:
>
> Peter Eisentraut wrote:
> > Tom Lane writes:
> >
> > > Quite awhile back, we had a discussion about removing "$" from the set
> > > of allowed characters in operator names, and instead allowing it as a
> > > non-first character in identifiers.
> >
> > I agree with the firs
Tom Lane wrote:
>
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > The problem is, discouraged or not, if there's a slot people will stick
> > something into ... meaning if it accepts a dollar, to hell with vendor
> > recommendations!
>
> I'm confused; are you voting against allowing dollar in identif
Tom Lane writes:
> Quite awhile back, we had a discussion about removing "$" from the set
> of allowed characters in operator names, and instead allowing it as a
> non-first character in identifiers.
I agree with the first one, but does it have to imply the second?
--
Peter Eisentraut [EMAIL
On Thu, Jan 09, 2003 at 10:49:33PM +0100, Peter Eisentraut wrote:
> Christopher Kings-Lynne writes:
>
> > Is there any way of making the 'up' arrow retrieve all of the last multiline
> > query, instead of just the last line?
>
> There is nothing technical that should prevent you from implementing
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 09, 2003 2:27 PM
> To: Jan Wieck
> Cc: Bruce Momjian; Peter Eisentraut; PostgreSQL HACKERS
> Subject: Re: [HACKERS] Dollar in identifiers
>
>
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > The proble
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > OK, Peter, to keep you and everyone happy, what changes are your
> > proposing to the existing code, if any. The only current behavior is
> > printing an IPv6 failure for IPv6-enabled backend in the server logs.
>
> Just bind to all addresses
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > Quite awhile back, we had a discussion about removing "$" from the set
> > of allowed characters in operator names, and instead allowing it as a
> > non-first character in identifiers.
>
> I agree with the first one, but does it have to imply the s
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 09, 2003 1:55 PM
> To: Peter Eisentraut
> Cc: Tom Lane; Jan Wieck; PostgreSQL HACKERS
> Subject: Re: [HACKERS] Dollar in identifiers
>
>
> Peter Eisentraut wrote:
> > Tom Lane writes:
> >
> >
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I notice that you can't explain stored plans, i.e., EXPLAIN EXECUTE.
> Might be handy to have.
Yeah, that was on my to-fix list also. There is more reason to have
this than just completeness: as things stand, EXPLAIN cannot teach you
anything about w
Jan Wieck <[EMAIL PROTECTED]> writes:
> The problem is, discouraged or not, if there's a slot people will stick
> something into ... meaning if it accepts a dollar, to hell with vendor
> recommendations!
I'm confused; are you voting against allowing dollar in identifiers?
I thought it was you that
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> The case I find interesting is where you're using plain "\e" to
>> re-edit a query interactively. If this query never gets into the
>> history buffer then you're lost: you won't be able to pull it back
>> for re-editing a second ti
Christopher Kings-Lynne writes:
> Is there any way of making the 'up' arrow retrieve all of the last multiline
> query, instead of just the last line?
There is nothing technical that should prevent you from implementing it.
But you need to come up with a reasonable system to keep the history
stra
Tom Lane writes:
> The case I find interesting is where you're using plain "\e" to
> re-edit a query interactively. If this query never gets into the
> history buffer then you're lost: you won't be able to pull it back
> for re-editing a second time.
If you call \e again immediately then you edi
I notice that you can't explain stored plans, i.e., EXPLAIN EXECUTE.
Might be handy to have.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregiste
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Quite awhile back, we had a discussion about removing "$" from the set
>> of allowed characters in operator names, and instead allowing it as a
>> non-first character in identifiers.
> I agree with the first one, but does it have t
Bruce Momjian writes:
> OK, Peter, to keep you and everyone happy, what changes are your
> proposing to the existing code, if any. The only current behavior is
> printing an IPv6 failure for IPv6-enabled backend in the server logs.
Just bind to all addresses you can find, IPv4 or IPv6. And leav
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Is there a time when QueryDesc->operation is not equal to
> QueryDesc->parsetree->cmdType?
I don't believe so. Not sure why the code bothers to store the
redundant field.
regards, tom lane
---(end of
On Wed, 2003-01-08 at 15:30, Christopher Kings-Lynne wrote:
> > > Is there any way of making the 'up' arrow retrieve all of the last multiline
> > > query, instead of just the last line? It's really annoying working with
> > > large multiline queries at the moment...
You could use ledit, piped wi
Is there a time when QueryDesc->operation is not equal to
QueryDesc->parsetree->cmdType?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.h
I agree. I think $ is too special to be mixed in with operators. It is
just used too frequently for variables.
---
Tom Lane wrote:
> Quite awhile back, we had a discussion about removing "$" from the set
> of allowed chara
Quite awhile back, we had a discussion about removing "$" from the set
of allowed characters in operator names, and instead allowing it as a
non-first character in identifiers. (It'd have to be non-first to avoid
ambiguity with parameter symbols "$nnn".) See, eg,
http://archives.postgresql.org/pg
On Thu, 9 Jan 2003, Bruce Momjian wrote:
> Rod Taylor wrote:
> > I'd tend to switch it to store \E QUERY BUFFER in the history, and
> > possibly remove the ability to use \e by itself -- or make \E FILENAME
> > and \e QUERY BUFFER.
> >
> > Since the use of \e isn't likely to be used in a programm
Hi guys,
As a curiosity thought, would it be possible to do something like:
\ep
Where this tells psql to get the query in the history prior to the \e,
and edit it interactively?
:-)
Regards and best wishes,
Justin Clift
--
"My grandfather once told me that there are two kinds of people: tho
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Rod Taylor wrote:
>> Since the use of \e isn't likely to be used in a programmatic
>> (automated) way, but only by users who could quickly figure it out.
> I don't think it makes sense to remove \e just to add history
> functionality.
Indeed, that would
Rod Taylor wrote:
> I'd tend to switch it to store \E QUERY BUFFER in the history, and
> possibly remove the ability to use \e by itself -- or make \E FILENAME
> and \e QUERY BUFFER.
>
> Since the use of \e isn't likely to be used in a programmatic
> (automated) way, but only by users who could qu
On Thu, 2003-01-09 at 10:42, Peter Mount wrote:
> On 9 Jan 2003, Rod Taylor wrote:
>
> > On Thu, 2003-01-09 at 10:12, Justin Clift wrote:
> > > Bruce Momjian wrote:
> > >
> > > > Let's suppose I am writing a query, and then I do \e to edit the query,
> > > > and I exit the editor and return to ps
On Thu, 09 Jan 2003 08:39:33 CST, the world broke into rejoicing as
"John Liu" <[EMAIL PROTECTED]> said:
> How do I know the clock on the machine you're
> running on will be set to the same time as the
> clock on the database? how postgre handle this
> internal?
You'll know because you already r
On 9 Jan 2003, Rod Taylor wrote:
> On Thu, 2003-01-09 at 10:12, Justin Clift wrote:
> > Bruce Momjian wrote:
> >
> > > Let's suppose I am writing a query, and then I do \e to edit the query,
> > > and I exit the editor and return to psql. Suppose I decide I want to
> > > reedit, so I up arrow.
On Thu, 09 Jan 2003 10:13:14 EST, the world broke into rejoicing as
Bruce Momjian <[EMAIL PROTECTED]> said:
> Justin Clift wrote:
> > Bruce Momjian wrote:
> >
> > > Let's suppose I am writing a query, and then I do \e to edit the query,
> > > and I exit the editor and return to psql. Suppose I d
On Thu, 2003-01-09 at 10:12, Justin Clift wrote:
> Bruce Momjian wrote:
>
> > Let's suppose I am writing a query, and then I do \e to edit the query,
> > and I exit the editor and return to psql. Suppose I decide I want to
> > reedit, so I up arrow. I would expect to get \e, not the query I just
Tom,
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > + #define _THREAD_SAFE
> > + #define _REENTRANT
> > + #define _POSIX_PTHREAD_SEMANTICS
> What is this stuff, and why isn't it wrapped in any sort of
> platform-specific test? If it's needed, why is it in only one .c
> fil
On 9 Jan 2003 at 10:13, Bruce Momjian wrote:
> Justin Clift wrote:
> > Bruce Momjian wrote:
> >
> > > Let's suppose I am writing a query, and then I do \e to edit the
> > > query, and I exit the editor and return to psql. Suppose I decide
> > > I want to reedit, so I up arrow. I would expect to
On Fri, 10 Jan 2003, Justin Clift wrote:
> Bruce Momjian wrote:
>
> > Let's suppose I am writing a query, and then I do \e to edit the query,
> > and I exit the editor and return to psql. Suppose I decide I want to
> > reedit, so I up arrow. I would expect to get \e, not the query I just
> > ed
Justin Clift wrote:
> Bruce Momjian wrote:
>
> > Let's suppose I am writing a query, and then I do \e to edit the query,
> > and I exit the editor and return to psql. Suppose I decide I want to
> > reedit, so I up arrow. I would expect to get \e, not the query I just
> > edited, no?
>
> Wouldn'
Bruce Momjian wrote:
Let's suppose I am writing a query, and then I do \e to edit the query,
and I exit the editor and return to psql. Suppose I decide I want to
reedit, so I up arrow. I would expect to get \e, not the query I just
edited, no?
Wouldn't it depend on how this gets implemented?
Justin Clift wrote:
> Dan Langille wrote:
>
> > As this is changing existing behaviour, I think adding an optional
> > switch to revert to the old behaviour is a good idea.
>
> Two thoughts:
>
> a) Is it possible to change the behavior of the history as we're
> discussing? Haven't heard Pete
resent with my real mail address...
On 9 Jan 2003 at 13:45, Peter Mount wrote:
> On Wed, 8 Jan 2003, Dan Langille wrote:
>
> > On 8 Jan 2003 at 12:28, Bruce Momjian wrote:
> >
> > > Tom Lane wrote:
> > > > "Alexander M. Pravking" <[EMAIL PROTECTED]> writes:
> > > > > On Wed, Jan 08, 2003 at 10:
Justin Clift wrote:
b) Do we really want to go to the effort of adding a switch to revert to
previous behaviour for something like this? It's almost definitely a
win to have \e commands appear in the history, and seems a bit to
trivial for adding switches for.
Bad wording there... "\e command
Dan Langille wrote:
As this is changing existing behaviour, I think adding an optional
switch to revert to the old behaviour is a good idea.
Two thoughts:
a) Is it possible to change the behavior of the history as we're
discussing? Haven't heard Peter's response to this.
b) Do we really wa
How do I know the clock on the machine you're
running on will be set to the same time as the
clock on the database? how postgre handle this
internal?
thanks.
johnl
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.pos
On 9 Jan 2003 at 9:15, Robert Treat wrote:
> On Thu, 2003-01-09 at 08:45, Peter Mount wrote:
> > On Wed, 8 Jan 2003, Dan Langille wrote:
> > > On 8 Jan 2003 at 12:28, Bruce Momjian wrote:
> > > > Tom Lane wrote:
> > > > > "Alexander M. Pravking" <[EMAIL PROTECTED]> writes:
> > > > > > On Wed, Jan
On Thu, 2003-01-09 at 08:45, Peter Mount wrote:
> On Wed, 8 Jan 2003, Dan Langille wrote:
> > On 8 Jan 2003 at 12:28, Bruce Momjian wrote:
> > > Tom Lane wrote:
> > > > "Alexander M. Pravking" <[EMAIL PROTECTED]> writes:
> > > > > On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
> > > >
t use in the configure stuff is
100% right...
Patches also at:
http://services.csl.co.uk/postgresql/diffs-20030109-configure.txt.gz
http://services.csl.co.uk/postgresql/diffs-20030109-libpq.txt.gz
Thanks, Lee.
Lee Kindness writes:
> Tom Lane writes:
> > Bruce Momjian <[EMAIL P
On Wed, 8 Jan 2003, Dan Langille wrote:
> On 8 Jan 2003 at 12:28, Bruce Momjian wrote:
>
> > Tom Lane wrote:
> > > "Alexander M. Pravking" <[EMAIL PROTECTED]> writes:
> > > > On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
> > > >> On Wednesday 08 January 2003 07:55, Christopher King
53 matches
Mail list logo
