Message-ID: <3E7122C8.1020902@xythos.com>
Date: Thu, 13 Mar 2003 16:31:04 -0800
From: Barry Lind <blind@xythos.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Roadmap for FE/BE protocol redesign
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>
In-Reply-To: <9947.1047595235@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


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