From: Tom Lane <tgl@sss.pgh.pa.us>
To: Barry Lind <blind@xythos.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Roadmap for FE/BE protocol redesign
Date: Thu, 13 Mar 2003 17:40:35 -0500
Message-ID: <9947.1047595235@sss.pgh.pa.us> (raw)
In-Reply-To: <3E70E6C8.3050201@xythos.com>
References: <19041.1047322279@sss.pgh.pa.us>
<3E6EEA9B.3050201@xythos.com>
<27307.1047485980@sss.pgh.pa.us>
<3E6FECAD.8030500@xythos.com>
<7189.1047577301@sss.pgh.pa.us>
<3E70E6C8.3050201@xythos.com>
Barry Lind <blind@xythos.com> writes:
> Tom Lane wrote:
>> See binary cursors ...
> Generally that is not an option. It either requires users to code to
> postgresql specific sql syntax, or requires the driver to do it
> magically for them.
Fair enough. I don't see anything much wrong with a GUC option that
says "send SELECT output in binary format". This is not really a
protocol issue since the ASCII and BINARY choices both exist at the
protocol level --- there is nothing in the protocol saying binary data
can only be returned by FETCH and not by SELECT. The main problem with
it in present releases is that binary data is architecture-dependent and
so encouraging its general use seems like a really bad idea. But if we
manage to get send/receive conversion routines in there, most of that
issue would go away.
> The describe request is generally only
> done once even though you may do multiple fetchs (unlike todays protocol
> which includes the describe information on every fetch, even if you are
> fetching one row at a time).
I'm less than excited about changing that, because it breaks clients
that don't want to remember past RowDescriptions (libpq being the
front-line victim), and it guarantees loss-of-synchronization failures
anytime the client misassociates rowdescription with query. In exchange
for that, we get what exactly? Fetching one row at a time is
*guaranteed* to be inefficient. The correct response if that bothers
you is to fetch multiple rows at a time, not to make a less robust
protocol.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: tgl@sss.pgh.pa.us, blind@xythos.com, pgsql-hackers@postgresql.org
Subject: Re: Roadmap for FE/BE protocol redesign
In-Reply-To: <9947.1047595235@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox