"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
