>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> Peter Eisentraut <peter_e@gmx.net> writes: >> A transform group is a named object attached to a type. A >>
transformgroup converts a user-defined type to a standard SQL >> type or vice versa. (The rationale being that
clientsknow how >> to handle standard SQL types.)
Tom> Hmm, I hope they didn't restrict the design so that transform Tom> groups could do *only* that; if so, they'd
befar less useful Tom> than I thought. (Your example below doesn't work if so, Tom> because "struct tm" isn't
SQL.)
I'm pretty sure that's how it is. Associated with each tranform group
is a FROM_SQL and a TO_SQL function, and each function, of course,
only returns an SQL type. That's how it got implemented in db2 ..
>> example timestamp to struct tm. Would you want to pass struct >> tm-data over the wire as a blob of 36 bytes?
Iwould rather >> get a standard binary representation with a length word, so a >> middle layer can still copy this
dataaround without having to >> be data type-aware.
There was some talk about standardizing wire representations, but
there was never enough momentum to get that going. By that time, the
standard became fairly Java-biased. IIRC, the decision was that this
would be addressed by the call-level interface bindings. So for
instance, with JDBC/SQLJ there are the SQLOutput and SQLInput streams
(similar in spirit to ObjectOutput and ObjectInput). The idea is to
map each database structured type to a Java class that implements the
SQLData interface. All this is very clearly laid out in the SQLJ
standard which is quite readable.
So, while things are well standardized in the Java world, they're
practically non-existant for the other client bindings.
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh