Re: [HACKERS] proposal psql \gdesc
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] proposal psql \gdesc |
Дата | |
Msg-id | alpine.DEB.2.20.1705081240000.3983@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] proposal psql \gdesc (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: [HACKERS] proposal psql \gdesc
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: