From: Barry Lind <blind@xythos.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Roadmap for FE/BE protocol redesign
Date: Thu, 13 Mar 2003 16:31:04 -0800
Message-ID: <3E7122C8.1020902@xythos.com> (raw)
In-Reply-To: <9947.1047595235@sss.pgh.pa.us>
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>
<9947.1047595235@sss.pgh.pa.us>
Tom Lane wrote:
> 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.
>
That would be great.
>
>>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.
I don't feel strongly either way on this one, but IIRC the SQL standard
for cursors only specifies fetching one record at a time (at least that
is how MSSQL and DB2 implement it). Thus portable code is likely to
only fetch one record at a time. The current row description isn't too
big, but with the changes being suggested it might become so.
thanks,
--Barry
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: blind@xythos.com, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
Subject: Re: Roadmap for FE/BE protocol redesign
In-Reply-To: <3E7122C8.1020902@xythos.com>
* 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