Re: [HACKERS] proposal psql \gdesc - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: [HACKERS] proposal psql \gdesc |
| Date | |
| Msg-id | CAFj8pRBXdTd=YCkcWo1xBCqA6h5iHDj=KQGk7w8JaCj47i0KmQ@mail.gmail.com Whole thread Raw |
| In response to | Re: [HACKERS] proposal psql \gdesc (Fabien COELHO <coelho@cri.ensmp.fr>) |
| Responses |
Re: [HACKERS] proposal psql \gdesc
(Fabien COELHO <coelho@cri.ensmp.fr>)
|
| List | pgsql-hackers |
Hi
2017-05-08 9:08 GMT+02:00 Fabien COELHO <coelho@cri.ensmp.fr>:
Hello Pavel,
A complement to my previous comments:Also, maybe it would be better if the statement is cleaned up server side at the end of the execution. Not sure how to achieve that, though, libpq seems to lack the relevant function:-(
"""although there is no libpq function for deleting a prepared
statement, the SQL DEALLOCATE statement can be used for that purpose."""
Hmmm... I have not found how to use DEALLOCATE to cleanup an unnamed statement, it does not allow a "zero-length" name. Maybe it could be extended somehow, or a function could be provided for the purpose, eg
by passing a NULL query to PQprepare...
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.
2. allow executing DEALLOCATE "";
3. add the missing PQdeallocate function to libpq?
Version 2 is server side, so it would not be compatible when connected to server running previous versions. Not desirable.
Version 3 may have implication at the protocol level and server side, if so it does not seem desirable to introduce such a change.
So maybe only version 1 is possible.
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. So there are not any possible conflict and only one unnamed prepared statement can exists. The overhead is like any call of PLpgSQL function where any embedded SQLs are prepared implicitly. So @0 is from my perspective safe. Looks so unnamed PP was designed for this short life PP.
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. Another reason for @0 is not necessity to generate some auxiliary name.
So in this case, I thinking @0 is good enough way (due unnamed PP behave), and can be enhanced by @3, but @3 requires wide discussion about design (and can be overkill for \gdesc command) and should be problem everywhere you use new client against old server. Same problem (you mentioned) has @2.
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.
Regards
Pavel
--
Fabien.
pgsql-hackers by date: