From: Tom Lane <tgl@sss.pgh.pa.us>
To: Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-hackers@postgreSQL.org
Cc: pgsql-interfaces@postgreSQL.org
Subject: Re: Transform groups (more FE/BE protocol issues)
Date: Mon, 05 May 2003 12:54:00 -0400
Message-ID: <28645.1052153640@sss.pgh.pa.us> (raw)
In-Reply-To: <46C15C39FEB2C44BA555E356FBCD6FA4961F96@m0114.s-mxs.net>
References: <46C15C39FEB2C44BA555E356FBCD6FA4961F96@m0114.s-mxs.net>
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> Yes, all sounds very reasonable. I would make the field wide enough to
> carry a pg_type.oid.
> A few values (that should optimally not conflict with pg_type oid's) could
> carry special meaning like 0 text, 1 native binary ...
Well, this is exactly why the contents are *not* OIDs. Zero isn't a
valid OID and I don't like assuming that 1 is either. Also if you want
to think that the codes might be forced by outside considerations (like
odbc standards) then OID is a bad idea.
If we were really doing this in a general fashion (which is not
happening for 7.4 ;-)) I would envision a system catalog that describes
transform groups --- but it would have a non-OID column that carries the
group ID to be used at the protocol level. We can pretty much choose
the width of that column at will --- either 1, 2, or 4 bytes could be
argued for, depending on how you want to make the tradeoff between
bandwidth and flexibility.
I'm leaning towards 1 or 2 bytes myself. I have a hard time envisioning
huge numbers of transform groups.
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, ZeugswetterA@spardat.at, peter_e@gmx.net, pgsql-hackers@postgreSQL.org
Subject: Re: Transform groups (more FE/BE protocol issues)
In-Reply-To: <28645.1052153640@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