Re: prepared statement "cu1" already exists (but it does not) - Mailing list pgsql-general

From Sebastien Flaesch
Subject Re: prepared statement "cu1" already exists (but it does not)
Date
Msg-id AM9P191MB1286990B716F5DED6BCDFF99B0072@AM9P191MB1286.EURP191.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: prepared statement "cu1" already exists (but it does not)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
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 <tgl@sss.pgh.pa.us>
Sent: Tuesday, April 9, 2024 6:36 PM
To: Sebastien Flaesch <sebastien.flaesch@4js.com>
Cc: pgsql-general <pgsql-general@lists.postgresql.org>
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 <sebastien.flaesch@4js.com> 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


pgsql-general by date:

Previous
From: Thiemo Kellner
Date:
Subject: Re: [Code: 0, SQL State: 0A000] when "typing" from pg_catalog
Next
From: Thiemo Kellner
Date:
Subject: Re: [Code: 0, SQL State: 0A000] when "typing" from pg_catalog