Re: [HACKERS] proposal psql \gdesc - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] proposal psql \gdesc
Date
Msg-id CAFj8pRCVxHg5_A3PyR+9Br3UK28FeVa18tDmATjh1F3PBfHJHw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] proposal psql \gdesc  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers


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

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Get stuck when dropping a subscription duringsynchronizing table
Next
From: Neha Khatri
Date:
Subject: Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()