Re: proposal psql \gdesc

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.

In response to

Responses

Browse pgsql-hackers by date

  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