Hiroshi Inoue [EMAIL PROTECTED] writes:
Good catch. Hmm this may be a serious problem because
there's no way to know the row count when we use EXECUTE
statements.
I wonder if EXECUTE could/should be made to return the appropriate
command status string for the executed statement, instead of
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Good catch. Hmm this may be a serious problem because
there's no way to know the row count when we use EXECUTE
statements.
I wonder if EXECUTE could/should be made to return the appropriate
command status string for the executed
Bruce Momjian [EMAIL PROTECTED] writes:
I think it should return EXECUTE with the counts from the commands.
Does that make sense?
No. It would break client libraries, which only expect command tags
INSERT, UPDATE, DELETE to be followed by counts. Also, INSERT has two
numbers associated with
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think it should return EXECUTE with the counts from the commands.
Does that make sense?
No. It would break client libraries, which only expect command tags
INSERT, UPDATE, DELETE to be followed by counts. Also, INSERT has two
On Fri, Dec 20, 2002 at 12:56:55PM -0500, Tom Lane wrote:
No. It would break client libraries, which only expect command tags
INSERT, UPDATE, DELETE to be followed by counts.
And MOVE, right?
Jeroen
---(end of broadcast)---
TIP 6: Have you
Bruce Momjian [EMAIL PROTECTED] writes:
It is easy to determine what tag to return? Remember the discussion on
rules and that only the original tag should be returned. Is there
always one obvious tag to an execute?
I would think we'd do it via the rule that we return the same thing
you'd get
http://www.cs.mcgill.ca/~kemme/papers/vldb00.html
Thanks for the link, Darren, I think everyone interested
in discussion should read it.
First, I like approach. Second, I don't understand why
ppl oppose pg-r 2pc. 2pc is just simple protocol to
perform distributed commits *after* distributed
I have been looking into the possibility of using a hashtable to speed
up x IN (SELECT y FROM ...) operations. Basically the idea is to run
the subselect once, loading its y outputs into an in-memory hashtable
(any duplicates can be discarded); then for each outer row, probe into
the hashtable to
unsubscribe
__
Yahoo! Cartoline: invia i tuoi auguri di Natale agli amici
http://it.yahoo.com/mail_it/foot/?http://it.greetings.yahoo.com
---(end of broadcast)---
TIP 2: you can
