Re: prepared statement "cu1" already exists (but it does not)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: prepared statement "cu1" already exists (but it does not)
Дата
Msg-id 3298762.1712597811@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: prepared statement "cu1" already exists (but it does not)  (Sebastien Flaesch <sebastien.flaesch@4js.com>)
Ответы Re: prepared statement "cu1" already exists (but it does not)  (Sebastien Flaesch <sebastien.flaesch@4js.com>)
Re: prepared statement "cu1" already exists (but it does not)  (Sebastien Flaesch <sebastien.flaesch@4js.com>)
Список pgsql-general
Sebastien Flaesch <sebastien.flaesch@4js.com> writes:
> I understand that the whole TX is aborted with PostgreSQL, and probably the deallocate is useless since stmt was
preparedinside the TX? 

As you can quickly discover with some manual experimentation,
both PREPARE and DEALLOCATE are nontransactional, in the sense
that if they succeed then the prepared statement will exist
(or not) even if the surrounding transaction block is later
rolled back.  This is pretty weird, and undocumented I think,
in terms of their role as SQL statements.
It makes a little more sense if you think about the equivalent
wire-protocol-level operations, which are meant to be used
by low-level client code that may not be aware of whether
there is a transaction block in progress.

> Is it an issue if I use the same name for a prepared statement and the server cursor? I mean:

From memory, I think those share the same "portal" namespace.

            regards, tom lane



В списке pgsql-general по дате отправления:

Предыдущее
От: Dominique Devienne
Дата:
Сообщение: Re: prepared statement "cu1" already exists (but it does not)
Следующее
От: Sebastien Flaesch
Дата:
Сообщение: Re: prepared statement "cu1" already exists (but it does not)