public inbox for [email protected]help / color / mirror / Atom feed
Re: prepared statement "cu1" already exists (but it does not) 3+ messages / 2 participants [nested] [flat]
* Re: prepared statement "cu1" already exists (but it does not) @ 2024-04-09 14:44 Sebastien Flaesch <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Sebastien Flaesch @ 2024-04-09 14:44 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: pgsql-general <[email protected]> Tom, > > 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. Can you please elaborate? Is it supported to do: PQprepare(pgConn, "cu1", "declare cu1 cursor for ... ", ... ) PQexecPrepared(pgConn, "cu1", ... ) ? So far this has always worked. Seb ________________________________ From: Tom Lane <[email protected]> Sent: Monday, April 8, 2024 7:36 PM To: Sebastien Flaesch <[email protected]> Cc: pgsql-general <[email protected]> Subject: Re: prepared statement "cu1" already exists (but it does not) EXTERNAL: Do not click links or open attachments if you do not recognize the sender. Sebastien Flaesch <[email protected]> writes: > I understand that the whole TX is aborted with PostgreSQL, and probably the deallocate is useless since stmt was prepared inside 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 ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: prepared statement "cu1" already exists (but it does not) @ 2024-04-09 16:36 Tom Lane <[email protected]> parent: Sebastien Flaesch <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Tom Lane @ 2024-04-09 16:36 UTC (permalink / raw) To: Sebastien Flaesch <[email protected]>; +Cc: pgsql-general <[email protected]> Sebastien Flaesch <[email protected]> writes: >>> 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. > Can you please elaborate? > Is it supported to do: > PQprepare(pgConn, "cu1", "declare cu1 cursor for ... ", ... ) > PQexecPrepared(pgConn, "cu1", ... ) > ? > So far this has always worked. Ah, sorry, what I should have said is that the SQL PREPARE command works with the same namespace as PQprepare (which is a thin wrapper over the wire-protocol Parse command). There is a different namespace for cursors. Cursors do share that namespace with the wire-protocol "portal" concept, but libpq doesn't directly expose portals. regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: prepared statement "cu1" already exists (but it does not) @ 2024-04-09 16:48 Sebastien Flaesch <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Sebastien Flaesch @ 2024-04-09 16:48 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: pgsql-general <[email protected]> Ok thanks Tom, My understanding from your last comment: Since prepared statements and server cursors use different name spaces, it's save to use the same name as in PQprepare(pgConn, "cu1", "declare cu1 cursor for ... ", ... ) Seb ________________________________ From: Tom Lane <[email protected]> Sent: Tuesday, April 9, 2024 6:36 PM To: Sebastien Flaesch <[email protected]> Cc: pgsql-general <[email protected]> Subject: Re: prepared statement "cu1" already exists (but it does not) EXTERNAL: Do not click links or open attachments if you do not recognize the sender. Sebastien Flaesch <[email protected]> writes: >>> 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. > Can you please elaborate? > Is it supported to do: > PQprepare(pgConn, "cu1", "declare cu1 cursor for ... ", ... ) > PQexecPrepared(pgConn, "cu1", ... ) > ? > So far this has always worked. Ah, sorry, what I should have said is that the SQL PREPARE command works with the same namespace as PQprepare (which is a thin wrapper over the wire-protocol Parse command). There is a different namespace for cursors. Cursors do share that namespace with the wire-protocol "portal" concept, but libpq doesn't directly expose portals. regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-04-09 16:48 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-04-09 14:44 Re: prepared statement "cu1" already exists (but it does not) Sebastien Flaesch <[email protected]> 2024-04-09 16:36 ` Tom Lane <[email protected]> 2024-04-09 16:48 ` Sebastien Flaesch <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox