Re: BUG #9198: psql -c 'SET; ...' not working - Mailing list pgsql-bugs

From Christoph Berg
Subject Re: BUG #9198: psql -c 'SET; ...' not working
Date
Msg-id 20140213131858.GB25703@msgid.credativ.de
Whole thread Raw
In response to Re: BUG #9198: psql -c 'SET; ...' not working  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #9198: psql -c 'SET; ...' not working
List pgsql-bugs
Re: Tom Lane 2014-02-12 <25094.1392219652@sss.pgh.pa.us>
> The reason this isn't a bug is that a -c command string is sent to the
> server as a single statement (PQexec call), and what "statement timeout"
> controls is the total time for the whole thing.  The SET operation can't
> change the already-running timer for the current statement.  It would
> affect the timeout for the next statement ... but there won't be one.
>=20
> Many people have complained that it's unintuitive that -c works this way
> rather than breaking up the string into multiple submissions the same way
> psql would do with normal input.  We're afraid to change it for fear of
> breaking applications, though.  If you want behavior more like psql's
> normal operation, consider
>=20
> echo "SET statement_timeout =3D '3s'; SELECT pg_sleep(2)" | psql

I think the docs don't really say that. The psql manpage says "single
transaction", but the problem here is rather "single command". I see
that "fixing" this would break the "one transaction" part, so it's
going to stay that way, but I'd propose something like this doc
update:

*** a/doc/src/sgml/ref/psql-ref.sgml
--- b/doc/src/sgml/ref/psql-ref.sgml
*************** PostgreSQL documentation
*** 100,106 ****
         string to divide it into multiple transactions.  This is
         different from the behavior when the same string is fed to
         <application>psql</application>'s standard input.  Also, only
!        the result of the last SQL command is returned.
        </para>
        </listitem>
      </varlistentry>
--- 100,111 ----
         string to divide it into multiple transactions.  This is
         different from the behavior when the same string is fed to
         <application>psql</application>'s standard input.  Also, only
!        the result of the last SQL command is returned.  <command>SET</>
!        commands that modify statement behavior will be ineffective because
!        they are part of the already running statement.  Most notably,
!        <literal>psql -c 'SET statement_timeout =3D 0; SELECT ...'</litera=
l>
!        will not work as expected.  (Use <literal>echo '...' | psql</liter=
al>
!        as above instead.)
        </para>
        </listitem>
      </varlistentry>


I'm actually unsure if there's more SETs that have this surprising
behavior, if statement_timeout is the only one, psql(1) should mention
that instead of what I wrote in the patch.

Mit freundlichen Gr=FC=DFen,
Christoph Berg
--=20
Senior Berater, Tel.: +49 (0)21 61 / 46 43-187
credativ GmbH, HRB M=F6nchengladbach 12080, USt-ID-Nummer: DE204566209
Hohenzollernstr. 133, 41061 M=F6nchengladbach
Gesch=E4ftsf=FChrung: Dr. Michael Meskes, J=F6rg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE

pgsql-bugs by date:

Previous
From: sharvarichorghe@gmail.com
Date:
Subject: BUG #9207: Functions Updations
Next
From: Matheus de Oliveira
Date:
Subject: Re: BUG #9198: psql -c 'SET; ...' not working