> * 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
