From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-hackers@postgreSQL.org
Cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] Last round (I think) of FE/BE protocol changes
Date: Tue, 13 May 2003 18:58:18 -0400
Message-ID: <19127.1052866698@sss.pgh.pa.us> (raw)
In-Reply-To: <Pine.LNX.4.44.0305140039580.1617-100000@peter.localdomain>
References: <Pine.LNX.4.44.0305140039580.1617-100000@peter.localdomain>
Peter Eisentraut <peter_e@gmx.net> writes:
> I think the "future versions" in this are going to be making this choice a
> datatype-specific session state. How can we make this transition
> smoother? Maybe 0 can be default, 1 text, 2 binary?
Why would a variable default be a good idea? The client *always* wants
to know what format the data is being returned in; I can't imagine
wanting a default that might be unknown to (any layer of) client
software.
One of the things that I think I have learned from this redesign is
that hidden state variables that affect the low-level protocol are
a bad idea. If we were to provide a changeable default format, I'd
want it to be reported by ParameterStatus messages. But I don't really
see the argument for providing it. You'd just have to clutter the
client-side stack with mechanisms for finding out what the default is.
That's about the same amount of grunge in the API as labeling data with
the format code in the first place ... but it's a lot easier to shoot
yourself in the foot by forgetting to handle it.
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, peter_e@gmx.net, pgsql-hackers@postgreSQL.org
Subject: Re: [INTERFACES] Last round (I think) of FE/BE protocol changes
In-Reply-To: <19127.1052866698@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