Skip site navigation (1) Skip section navigation (2)

Re: EXECUTE command tag returns actual command

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Kris Jurka <books(at)ejurka(dot)com>, pgsql-patches(at)postgresql(dot)org,pgsql-jdbc(at)postgresql(dot)org
Subject: Re: EXECUTE command tag returns actual command
Date: 2004-04-20 04:15:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbcpgsql-patches
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Your patch has been added to the PostgreSQL unapplied patches list at:

> Kris Jurka wrote:
>> This patch makes the EXECUTE command's completion tag return the 
>> completion tag of the actual statement executed.

While I don't have any strong reason to object to this, the reason
Kris wanted it was to help let the JDBC driver use "EXECUTE prepared-stmt"
as its basic mechanism for executing pre-prepared statements --- and
there are a couple reasons why he should abandon that idea in favor of
using V3-protocol Bind/Execute messages.

If he goes over to using Bind/Execute then the JDBC driver will have no
need for this patch.  In that case we ought to stop and think whether
sticking to the existing behavior isn't the right thing to do; it wins
on backwards-compatibility grounds and we have no other use-cases saying
we should change.

Not a big complaint, but something to consider before applying.

			regards, tom lane

PS: If you do apply, the EXECUTE reference page needs to have an
"Output" section added explaining that it returns a tag other than the
default "EXECUTE".

In response to


pgsql-patches by date

Next:From: Alvaro HerreraDate: 2004-04-20 05:32:55
Subject: Re: Basic subtransaction facility
Previous:From: Bruce MomjianDate: 2004-04-20 01:53:10
Subject: Re: pg_restore ignore error patch v2

pgsql-jdbc by date

Next:From: Anton KomarevtsevDate: 2004-04-20 05:37:36
Subject: Re: binary data in `bytea' column
Previous:From: Oliver JowettDate: 2004-04-20 02:57:53
Subject: Re: Prepared Statements and large where-id-in constant blocks?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group