From: Sailesh Krishnamurthy <sailesh@cs.berkeley.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Transform groups (more FE/BE protocol issues)
Date: 05 May 2003 19:21:51 -0700
Message-ID: <bxyfznsrf0g.fsf@datafix.CS.Berkeley.EDU> (raw)
In-Reply-To: <21371.1052182158@sss.pgh.pa.us>
References: <Pine.LNX.4.44.0305052201430.1785-100000@peter.localdomain>
<21371.1052182158@sss.pgh.pa.us>
>>>>> "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
>> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: sailesh@cs.berkeley.edu, tgl@sss.pgh.pa.us, peter_e@gmx.net, pgsql-hackers@postgresql.org
Subject: Re: Transform groups (more FE/BE protocol issues)
In-Reply-To: <bxyfznsrf0g.fsf@datafix.CS.Berkeley.EDU>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox