Re: Transform groups (more FE/BE protocol issues)

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

Responses

Browse pgsql-hackers by date

  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?

Browse pgsql-interfaces by date

  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)