Re: InitPostgres and flatfiles question
От | Tom Lane |
---|---|
Тема | Re: InitPostgres and flatfiles question |
Дата | |
Msg-id | 17180.1167925008@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: InitPostgres and flatfiles question (Markus Schiltknecht <markus@bluegap.ch>) |
Ответы |
Re: InitPostgres and flatfiles question
Re: InitPostgres and flatfiles question Re: InitPostgres and flatfiles question Re: InitPostgres and flatfiles question |
Список | pgsql-hackers |
Markus Schiltknecht <markus@bluegap.ch> writes: > I've just found the stumbling block: the -c option of psql wraps all in > a transaction, as man psql says: > ... > Thank you for clarification, I wouldn't have expected that (especially > because CREATE DATABASE itself says, it cannot be run inside a > transaction block... A transaction block (with BEGIN and COMMIT) seems > to be more than just a transaction, right?) Hm, that's an interesting point. psql's -c just shoves its whole argument string at the backend in one PQexec(), instead of dividing at semicolons as psql does with normal input. And so it winds up as a single transaction because postgres.c doesn't force a transaction commit until the end of the querystring. But that's not a "transaction block" in the normal sense and so it doesn't trigger the PreventTransactionChain defense in CREATE DATABASE and elsewhere. I wonder whether we ought to change that? The point of PreventTransactionChain is that we don't want the user rolling back the statement post-completion, but it seems thatpsql -c 'CREATE DATABASE foo; ABORT; BEGIN; ...' would bypass the check. regards, tom lane
В списке pgsql-hackers по дате отправления: