From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal psql \gdesc |
Date: | 2017-05-08 10:59:01 |
Message-ID: | alpine.DEB.2.20.1705081240000.3983@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2017-05-08 11:13:15 | Re: Get stuck when dropping a subscription during synchronizing table |
Previous Message | Fabien COELHO | 2017-05-08 10:38:26 | Re: Other formats in pset like markdown, rst, mediawiki |