Re: BUG #9198: psql -c 'SET; ...' not working
От | David Johnston |
---|---|
Тема | Re: BUG #9198: psql -c 'SET; ...' not working |
Дата | |
Msg-id | 1392307957238-5791873.post@n5.nabble.com обсуждение исходный текст |
Ответ на | Re: BUG #9198: psql -c 'SET; ...' not working (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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.
В списке pgsql-bugs по дате отправления: