Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands
От | Yugo NAGATA |
---|---|
Тема | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands |
Дата | |
Msg-id | 20221110144859.d9004fdd47396fe64fe032da@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands
|
Список | pgsql-hackers |
On Wed, 09 Nov 2022 11:38:05 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: > > This has broken the following use: > > > parse: create temporary table t1 (a int) on commit drop > > bind > > execute > > parse: analyze t1 > > bind > > execute > > parse: select * from t1 > > bind > > execute > > sync > > > I think the behavior of IsInTransactionBlock() needs to be further > > refined to support this. > > Hmm. Maybe the right way to think about this is "if we have completed an > EXECUTE, and not yet received a following SYNC, then report that we are in > a transaction block"? But I'm not sure if that breaks any other cases. Or, in that case, regarding it as an implicit transaction if multiple commands are executed in a pipeline as proposed in [1] could be another solution, although I have once withdrawn this for not breaking backward compatibility. Attached is the same patch of [1]. [1] https://www.postgresql.org/message-id/20220728105134.d5ce51dd756b3149e9b9c52c%40sraoss.co.jp Regards, Yugo Nagata -- Yugo NAGATA <nagata@sraoss.co.jp>
В списке pgsql-hackers по дате отправления: