To: "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Cc: "Peter Eisentraut" <peter_e@gmx.net>,
	pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
Subject: Re: Transform groups (more FE/BE protocol issues) 
In-reply-to: <46C15C39FEB2C44BA555E356FBCD6FA4961F96@m0114.s-mxs.net> 
References: <46C15C39FEB2C44BA555E356FBCD6FA4961F96@m0114.s-mxs.net>
Comments: In-reply-to "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
	message dated "Mon, 05 May 2003 18:13:57 +0200"
Date: Mon, 05 May 2003 12:54:00 -0400
Message-ID: <28645.1052153640@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"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