Re: About server side prepare

Hiroshi Inoue <Inoue@tpf.co.jp> 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 "EXECUTE".

regards, tom lane

Tom Lane wrote:

Hiroshi Inoue <Inoue@tpf.co.jp> 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 "EXECUTE".

I think it should return "EXECUTE" with the counts from the commands.
Does that make sense?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> 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 it, the others only one; if we allow both those
cases for EXECUTE then life gets even worse for the client library.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> 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 it, the others only one; if we allow both those
cases for EXECUTE then life gets even worse for the client library.

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?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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

Bruce Momjian <pgman@candle.pha.pa.us> 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 if you directly issued the query that appears as the body
of the PREPARE command. All the special cases for rules and so on
seem to apply the same way if you do that.

regards, tom lane

"Jeroen T. Vermeulen" <jtv@xs4all.nl> writes:

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?

Mph ... PQcmdTuples only knows about INSERT/UPDATE/DELETE. Looks like
we already made this mistake once before ;-).

regards, tom lane

Tom Lane wrote:

Hiroshi Inoue <Inoue@tpf.co.jp> 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 "EXECUTE".

Maybe it's preferable.

regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/

Hiroshi Inoue <Inoue@tpf.co.jp> 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 "EXECUTE".

Maybe it's preferable.

I agree. Command status string is pretty essential!

Chris