Hello Pavel,

After giving it some thoughts, I see three possible solutions:

0. Do nothing about it.
   I would prefer the prepare is cleaned up.

1. assign a special name, eg "_psql_gdesc_", so that
   DEALLOCATE "_psql_gdesc_" can be issued afterwards.


The doc says about unnamed prepared statements - any new unnamed prepared
statement deallocates previous by self. From psql environment is not
possible to create unnamed prepared statement.

That is a good point. It seems that it is not possible to execute it either.

I prefer @0 agaisnt @1 because workflow is simple and robust. If unnamed PP
doesn't exists, then it will be created, else it will be replaced. @1 has
little bit more complex workflow, because there is not command like
DEALLOCATE IF EXISTS, so I have to ensure deallocation in all possible

ISTM That it is only of the PQprepare succeeded, so there should be only one point, at the end of the corresponding OK condition?

Another reason for @0 is not necessity to generate some auxiliary

Yes. I do not like special names either. But I do not like keeping objects lives if they are dead. Not sure which is worst.

My opinion in this case is not too strong - just I see the advantages of @0
(robust and simple) nice. The question is about cost of unwanted allocated
PP to end of session.

My opinion is not strong either, it is more the principle that I do not like to let things forever live in the server while they are known dead.

Hmmm. Strange. For some obscure reason, the unnamed prepared statement does not show in pg_prepared_statements:

  calvin=# PREPARE test AS SELECT 2;
  calvin=# EXECUTE test;
    -- 2
  calvin=# SELECT 1 AS one \gdesc
    -- one | integer
  calvin=# SELECT * FROM  pg_prepared_statements ;
    -- just one row:
    -- test | PREPARE test AS SELECT 2; │7..

Conclusion: Maybe let it as solution 0 for the time being, with a comment telling that it will be cleaned on the next unnamed PQprepare, and the committer will have its opinion.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to