Re: BUG #9198: psql -c 'SET; ...' not working

From: David Johnston <polobo(at)yahoo(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #9198: psql -c 'SET; ...' not working
Date: 2014-02-13 16:12:37
Message-ID: 1392307957238-5791873.post@n5.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tom Lane-2 wrote
> 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.

The wording of the documentation implies, though, that a single statement
has component statements that are independently subject to transaction
semantics.

"If the command string contains multiple SQL commands, they are processed in
a single transaction, unless there are explicit BEGIN/COMMIT commands
included in the string to divide it into multiple transactions."

Is there any support for making these component statements also operate on
their own timeout timers? This is not that infrequent a question and at
minimum the documentation could be more clear. That people are wanting to
do this means that enhancement is something to consider as well - though not
something that strikes me as being that useful generally.

I am thinking something like "substatement_timeout" that if unset would
resolve to the current value of "statement_timeout" but if set would cause
all subsequent sub-statements to operate on that timer while the entire
super-statement would continue to operate on the original timer.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-9198-psql-c-SET-not-working-tp5791581p5791873.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David Johnston 2014-02-13 16:24:30 Re: BUG #9202: C Functions crash database too easily
Previous Message Tom Lane 2014-02-13 16:04:37 Re: BUG #9202: C Functions crash database too easily