From: Grant Finnemore <grantf@guruhut.co.za>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: First draft of new FE/BE protocol spec posted for comments
Date: Wed, 16 Apr 2003 07:24:04 +0200
Message-ID: <3E9CE8F4.6060504@guruhut.co.za> (raw)
In-Reply-To: <10770.1050448110@sss.pgh.pa.us>
References: <10770.1050448110@sss.pgh.pa.us>
As it currently stands, we have functions that are capable of returning
multi-column rows. Would the result of a FunctionCall message be to return
a FunctionCallResult and optional RowDescription, RowData messages?
I dont read that into the document as it stands tho'
http://candle.pha.pa.us/main/writings/pgsql/sgml/protocol-flow.html
Regards,
Grant
Tom Lane wrote:
> I have committed a first-draft revision of the FE/BE protocol document;
> you can read it at
> http://candle.pha.pa.us/main/writings/pgsql/sgml/protocol.html
> or in a few hours at
> http://developer.postgresql.org/docs/postgres/protocol.html
> I'd appreciate it if people would look it over for both presentation
> and content.
>
> There are a couple of loose ends that are still bothering me --- please
> comment:
>
> The new Execute command (part of the extended query protocol) has a
> field saying whether to return data in text or binary format. When
> retrieving from a cursor, it is not clear whether this should override
> the declaration of the cursor (BINARY or not). I am inclined to think
> that it should, but a possible compromise is to add a third value of the
> field meaning "don't care", in which case you'd get back text in all
> cases except when reading a cursor declared BINARY. This would be
> strictly for backwards compatibility though, and so maybe it doesn't
> matter. Old apps will probably be going through the simple-Query
> interface, which will give them the old behavior.
>
> I have dropped the CursorResponse message from the protocol, as it
> didn't seem to be doing anything useful; does anyone care about it?
>
> The document as it stands is a little bit schizoid about binary data
> formats. The new message types I've added are currently specified to
> use a representation that matches the COPY BINARY file format: an int16
> typlen (replaced with 0 if NULL), followed by a field value, where if
> typlen = -1 the first four bytes of the field value are self-inclusive
> length. The existing message types that handle binary data (BinaryRow,
> FunctionCall, FunctionResult) do it differently: a physical length (not
> counting self) followed by data. This is a bit of a mess, and I think
> it would make sense to standardize the representation one way or the
> other. The reason I'm inclined to move away from the old representation
> is that it's effectively broken on machines where MAXALIGN is greater
> than four: because it strips the length word out of the "contents" of
> varlena datatypes, the remainder of the varlena is not correctly aligned
> when stored in libpq memory. (The mail list archives seem to be down at
> the moment, so I can't give a URL, but there was a discussion of this
> point in pgsql-hackers on 2-Aug-99.) This will clearly be a
> user-visible change for people using binary cursors, but I think we
> *must* change it now or be stuck with the old mistake forever.
>
> An alternative approach, assuming we get as far as implementing
> architecture-independent binary representations, is to change the COPY
> BINARY file format to use them, and then the issue largely goes away ---
> we can stick with the existing layout for BinaryRow and make the other
> FE/BE messages use a similar format. But in either case, something
> breaks --- either binary cursors or COPY BINARY files. Any preference
> which to break?
>
> regards, tom lane
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
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: grantf@guruhut.co.za, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
Subject: Re: First draft of new FE/BE protocol spec posted for comments
In-Reply-To: <3E9CE8F4.6060504@guruhut.co.za>
* 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