Re: [HACKERS] proposal psql \gdesc

Поиск
Список
Период
Сортировка
Искать
От
Fabien COELHO
Тема
Re: [HACKERS] proposal psql \gdesc
Дата
в 13:59:01
Msg-id
alpine.DEB.2.20.1705081240000.3983@lancre
Ответ на
Список
Дерево обсуждения
[HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] proposal psql \gdesc Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: [HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] proposal psql \gdesc Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] proposal psql \gdesc Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] proposal psql \gdesc Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] proposal psql \gdesc Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] proposal psql \gdesc Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] proposal psql \gdesc Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] proposal psql \gdesc Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] proposal psql \gdesc Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] proposal psql \gdesc Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] proposal psql \gdesc Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] proposal psql \gdesc Brent Douglas <brent.n.douglas@gmail.com>
Re: [HACKERS] proposal psql \gdesc Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] proposal psql \gdesc Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] proposal psql \gdesc Fabien COELHO <coelho@cri.ensmp.fr>
Re: [HACKERS] proposal psql \gdesc Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>
Re: [HACKERS] proposal psql \gdesc Pavel Stehule <pavel.stehule@gmail.com>

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 по дате отправления
От: Fabien COELHO
Дата:
От: Masahiko Sawada
Дата:
FAQ