From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Peter Eisentraut" <peter_e(at)gmx(dot)net> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org>, <pgsql-interfaces(at)postgreSQL(dot)org> |
Subject: | Re: Transform groups (more FE/BE protocol issues) |
Date: | 2003-05-05 16:13:57 |
Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961F96@m0114.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-interfaces |
> * 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
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2003-05-05 16:14:52 | Re: Why are triggers semi-deferred? |
Previous Message | Tom Lane | 2003-05-05 16:09:29 | Re: Why are triggers semi-deferred? |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-05-05 16:54:00 | Re: Transform groups (more FE/BE protocol issues) |
Previous Message | Tom Lane | 2003-05-05 14:51:50 | Re: Transform groups (more FE/BE protocol issues) |