X-Original-To: pgsql-hackers@postgresql.org
Received: from spampd.localdomain (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP
	id 6C70247622E; Wed,  9 Apr 2003 01:05:37 -0400 (EDT)
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
	by postgresql.org (Postfix) with ESMTP
	id B4A8F476227; Wed,  9 Apr 2003 01:05:36 -0400 (EDT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.12.9/8.12.9) with ESMTP id h3955V2L004514;
	Wed, 9 Apr 2003 01:05:32 -0400 (EDT)
To: Joe Conway <mail@joeconway.com>
Cc: pgsql-hackers@postgresql.org, pgsql-interfaces@postgresql.org
Subject: Re: [INTERFACES] More protocol discussion: breaking down query
	processing
In-reply-to: <3E932F1A.80109@joeconway.com> 
References: <24009.1049325358@sss.pgh.pa.us> <3E932F1A.80109@joeconway.com>
Comments: In-reply-to Joe Conway <mail@joeconway.com>
	message dated "Tue, 08 Apr 2003 13:20:42 -0700"
Date: Wed, 09 Apr 2003 01:05:31 -0400
Message-ID: <4513.1049864731@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Spam-Status: No, hits=-32.5 required=5.0
	tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	REFERENCES,REPLY_WITH_QUOTES autolearn=ham	version=2.50
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-Archive-Number: 200304/296
X-Sequence-Number: 37786

Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> These protocol operations are interoperable with the SQL-level commands
>> for prepared queries and cursors, in the sense that a prepared query or
>> open cursor can be created either way and then used either way.
>> (Alternatively we might think that this is a bad idea, and that
>> protocol-level operations should use a different namespace from SQL
>> commands, so that application-requested operations can't interfere with
>> state that the client-side library has set up.  Any opinions?)

> Does this mean that a statement PREPAREd at the protocol level could be 
> EXECUTEd at the sql level? If that's the case, I'd tend to agree it is a 
> bad idea.

I'm of two minds about it.  On the basis of flexibility and ease of
debugging I'd think that sharing one namespace is good.  But I suppose
a client library that wants to defend itself against clueless
application programmers might prefer a separate namespace.

> I'd think that binary support at the protocol level would obsolete the 
> need for the DECLARE BINARY CURSOR command.

Yeah, but making something obsolete is not the same as being willing to
remove it immediately.  If we keep DECLARE BINARY CURSOR around, how
should it act?

> A related question: how difficult would it be to support the ability to 
> specify specific attributes as binary, while the rest are not.

I'd prefer not to go there.  It'd be messy and I don't see that it has
any use for common client libraries.  (Remember that most of this
discussion has focused on serving client libs that don't want to know
very much about the queries they're passing on --- so how are they going
to know which columns to ask for in binary?)

			regards, tom lane