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 Kings-Lynne
wrote:
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 08, 2003 at 10:53:51AM
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?
Dan Langille wrote:
snip
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
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
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
file?
It's
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:
snip
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
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 run NTP
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 PROTECTED] writes
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:
On Wednesday 08
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:53:51AM +0100, Ian
Justin Clift wrote:
Dan Langille wrote:
snip
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
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 with psql
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 what
-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:
Quite awhile
-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 problem is,
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,
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,
With
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 you can
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 second?
I
Bruce Momjian wrote:
snip
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
Justin Clift wrote:
Bruce Momjian wrote:
snip
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
unsubsriebMSN 8: advanced junk mail protection and 2 months FREE*
On 9 Jan 2003 at 10:13, Bruce Momjian wrote:
Justin Clift wrote:
Bruce Momjian wrote:
snip
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,
On Thu, 2003-01-09 at 10:12, Justin Clift wrote:
Bruce Momjian wrote:
snip
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
On 9 Jan 2003, Rod Taylor wrote:
On Thu, 2003-01-09 at 10:12, Justin Clift wrote:
Bruce Momjian wrote:
snip
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
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:
snip
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
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 quickly
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 defeat
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:
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 programmatic
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,
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
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
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
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 it.
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
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 identifiers?
I
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 first one, but does it
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
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 take a
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, 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 second time.
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 then you're
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 leave
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 to imply the
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 time.
If you
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
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 edit the
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
50 matches
Mail list logo
