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

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

Tom> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> A transform group is a named object attached to a type. A
>> transform group converts a user-defined type to a standard SQL
>> type or vice versa. (The rationale being that clients know 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 be far 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? I would rather
>> get a standard binary representation with a length word, so a
>> middle layer can still copy this data around 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