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: