Re: proposal psql \gdesc

Hi

2017-05-08 9:08 GMT+02:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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.
>