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
ways.
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
name.
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.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers