Thread: EXECUTE command tag returns actual command

EXECUTE command tag returns actual command

From
Kris Jurka
Date:
This patch makes the EXECUTE command's completion tag return the
completion tag of the actual statement executed.  This allows the
correct update count to be returned for UPDATE/INSERT/DELETE
statements.  Per discussion on hackers here:

http://archives.postgresql.org/pgsql-hackers/2004-03/msg00923.php

Kris Jurka

Attachment

Re: EXECUTE command tag returns actual command

From
Bruce Momjian
Date:
Your patch has been added to the PostgreSQL unapplied patches list at:

    http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------


Kris Jurka wrote:
>
> This patch makes the EXECUTE command's completion tag return the
> completion tag of the actual statement executed.  This allows the
> correct update count to be returned for UPDATE/INSERT/DELETE
> statements.  Per discussion on hackers here:
>
> http://archives.postgresql.org/pgsql-hackers/2004-03/msg00923.php
>
> Kris Jurka

Content-Description:

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

--
  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

Re: EXECUTE command tag returns actual command

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.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".

Re: [PATCHES] EXECUTE command tag returns actual command

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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".

Nice:

    test=> CREATE TABLE test(x int);
    CREATE TABLE
    test=> PREPARE x(int) AS INSERT INTO test VALUES ($1);
    PREPARE
    test=> EXECUTE x(3);
    INSERT 17210 1

I have applied the attached patch that updates the EXECUTE docs to
mention the tag will match the PREPARE.  Shame it is only available
after execute.  If it could be known before, I could allow log_statement
to trigger printing depending on the type of tag.

I have also updated the log_statement docs to more clearly explain that
log_statement doesn't properly know what type of command is being
execute.  log_statement does handle PREPARE properly though.

--
  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
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.261
diff -c -c -r1.261 runtime.sgml
*** doc/src/sgml/runtime.sgml    21 Apr 2004 13:18:28 -0000    1.261
--- doc/src/sgml/runtime.sgml    22 Apr 2004 04:16:29 -0000
***************
*** 2135,2150 ****
          <literal>UPDATE</>, <literal>DELETE</>, <literal>TRUNCATE</>,
          and <literal>COPY FROM</>. <literal>PREPARE</> and
          <literal>EXPLAIN ANALYZE</> statements are also considered for
!         appropriate commands. The default is <literal>none</>. Only
!         superusers can reduce the detail of this option if it has been
!         set by an administrator.
         </para>

         <note>
          <para>
!          When the <command>EXECUTE</command> statement is logged, only
!          the name of the prepared statement is recorded, not the
!          entire prepared statement.
          </para>

          <para>
--- 2135,2153 ----
          <literal>UPDATE</>, <literal>DELETE</>, <literal>TRUNCATE</>,
          and <literal>COPY FROM</>. <literal>PREPARE</> and
          <literal>EXPLAIN ANALYZE</> statements are also considered for
!         appropriate commands.
!        </para>
!        <para>
!         The default is <literal>none</>. Only superusers can reduce
!         the detail of this option if it has been set by an administrator.
         </para>

         <note>
          <para>
!          The <command>EXECUTE</command> statement not considered a
!          <literal>ddl</> or <literal>mod</> statement.  When it is logged,
!          only the name of the prepared statement is reported, not the
!          actual prepared statement.
          </para>

          <para>
Index: doc/src/sgml/ref/execute.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/execute.sgml,v
retrieving revision 1.8
diff -c -c -r1.8 execute.sgml
*** doc/src/sgml/ref/execute.sgml    26 Jan 2004 17:26:30 -0000    1.8
--- doc/src/sgml/ref/execute.sgml    22 Apr 2004 04:16:29 -0000
***************
*** 45,50 ****
--- 45,52 ----
    </para>

    <para>
+    The command tag returned by <command>EXECUTE</command>
+    is that of the prepared statement, and not <literal>EXECUTE</>.
     For more information on the creation and usage of prepared statements,
     see <xref linkend="sql-prepare" endterm="sql-prepare-title">.
    </para>