From: Tom Lane <tgl@sss.pgh.pa.us>
To: Joe Conway <mail@joeconway.com>
Cc: pgsql-hackers@postgresql.org
Cc: pgsql-interfaces@postgresql.org
Subject: Re: [INTERFACES] More protocol discussion: breaking down query processing
Date: Wed, 09 Apr 2003 01:05:31 -0400
Message-ID: <4513.1049864731@sss.pgh.pa.us> (raw)
In-Reply-To: <3E932F1A.80109@joeconway.com>
References: <24009.1049325358@sss.pgh.pa.us>
<3E932F1A.80109@joeconway.com>
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
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, mail@joeconway.com, pgsql-hackers@postgresql.org
Subject: Re: [INTERFACES] More protocol discussion: breaking down query processing
In-Reply-To: <4513.1049864731@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