2017-05-08 12:59 GMT+02:00 Fabien COELHO <coe...@cri.ensmp.fr>: > > 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: >
looks like the design. Unnamed PP is near to PP created by PLpgSQL. > > 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. > good decision. Thank you for review. I'll send new version early. Regards Pavel > > -- > Fabien.