Re: proposal psql \gdesc

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal psql \gdesc
Date: 2017-05-08 12:30:06
Message-ID: CAFj8pRCVxHg5_A3PyR+9Br3UK28FeVa18tDmATjh1F3PBfHJHw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Neha Khatri 2017-05-08 12:38:21 Re: Should pg_current_wal_location() become pg_current_wal_lsn()
Previous Message Masahiko Sawada 2017-05-08 12:04:12 Re: Get stuck when dropping a subscription during synchronizing table