Обсуждение: Re: Transform groups (more FE/BE protocol issues)

> * ISTM the most natural granularity for specifying transform group is at
> the column level.  I can't see a good use-case for varying transform
> type across rows of a select result, but being able to select it for
> each column has clear usefulness.

Yes, all sounds very reasonable. I would make the field wide enough to
carry a pg_type.oid. Eventually the backend could call the correct conversion functions from column type to specified
type.

This would be ideal for ecpg's requirements for bind.

A few values (that should optimally not conflict with pg_type oid's) could
carry special meaning like 0 text, 1 native binary ...
Maybe the builtins should also have special values (maybe conform to odbc types or esql types ?)

Does not tie to bind groups, but those could maybe be given special ranges,
or be only available per resultset and not per column.

Specifying the type once per bind is imho really sufficient.
Maybe a rebind could be allowed to switch inbetween ?

Andreas

"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