Re: Frontend/backend protocol improvements proposal (request).

From: Noah Misch <noah(at)leadboat(dot)com>
To: Dmitriy Igrishin <dmitigr(at)gmail(dot)com>
Cc: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Frontend/backend protocol improvements proposal (request).
Date: 2013-09-05 01:17:47
Message-ID: 20130905011747.GB139935@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Fri, Jun 21, 2013 at 12:37:32PM +0400, Dmitriy Igrishin wrote:
> 2013/6/21 Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
> > Dmitriy Igrishin wrote:
> > > While developing a C++ client library for Postgres I felt lack of extra
> > > information in command tags in the CommandComplete (B) message
> > > for the following commands:
> > > PREPARE;
> > > DEALLOCATE;
> > > DECLARE;
> > > CLOSE;
> > > LISTEN;
> > > UNLISTEN;
> > > SET;
> > > RESET.
> > > Namely, for example, users of my library can prepare statements by using
> > > protocol directly or via PREPARE command. Since the protocol does not
> > > supports prepared statement deallocation, I wrote a wrapper over
> > DEALLOCATE
> > > command. The library knows about all prepared statements and
> > > invalidates them automatically when user performs deallocate() wrapper.
> > > But users can go with DEALLOCATE command directly and in these cases
> > > I need to query the database to get the list of currently prepared
> > statements
> > > whenever CommandComplete message with DEALLOCATE command tag
> > > is consumed. Moreover, I need to do it *synchronously* and this breaks
> > > asynchronous API.
> > > I propose to include name of the object in the CommandComplete (B)
> > > message for the above commands.
> >
> > That would be a change in the protocol, so it's not likely to happen
> > soon. There is a page where proposed changes to the wire protocol
> > are collected: http://wiki.postgresql.org/wiki/Todo#Wire_Protocol_Changes
>
> Well, even if this proposal moves to the TODO, it would be nice.

That's worth at least considering when we start to revise the protocol, so I
have added it to the TODO list.

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adarsh Sharma 2013-09-05 04:43:34 LogStash For Analysing Postgres DB server Logs
Previous Message Adrian Klaver 2013-09-05 00:48:39 Re: [GENERAL] Call for design: PostgreSQL mugs

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-09-05 01:26:28 Re: strange IS NULL behaviour
Previous Message Bruce Momjian 2013-09-05 01:01:54 Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers