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 07:08:29 |
Message-ID: | alpine.DEB.2.20.1705080854380.3983@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2017-05-08 07:09:56 | Re: transition table behavior with inheritance appears broken (was: Declarative partitioning - another take) |
Previous Message | Noah Misch | 2017-05-08 07:03:58 | Re: SUBSCRIPTIONS and pg_upgrade |