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

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.)

Hmm, I hope they didn't restrict the design so that transform groups
could do *only* that; if so, they'd be far less useful than I thought.
(Your example below doesn't work if so, because "struct tm" isn't SQL.)

> Here's an example: a set of transform groups (for various data types)
> that convert SQL data types to more C-like types, for 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.

Sure, but the length word now becomes part of the protocol wrapper
rather than being considered part of the data. A struct tm
representation seems like a fine thing to me (at least if you like
struct tm, which I don't especially --- but if that's what your app is
coded to use, then that is exactly what you want).

> In fact, this suggests that the format field should not be represented at
> all in the protocol and only be handled as session state. Users can just
> say "I want these types in text and these types in binary" and that is
> respected for the rest of the session.

I don't think I like that, because it assumes that the client side of
things is monolithic, which it is not. The client library (libpq, jdbc,
etc) may or may not be aware of what the client application has done,
and neither of them may be aware of what the user has done via GUC
settings or interactive SQL commands. One of the things we're trying to
fix in this protocol revision is to ensure that the client library has
enough information to do its job, *without* any assumptions about what
the user is doing.

Barry gave a fine example of this, which was that JDBC has a hard time
parsing timestamp values (as it's supposed to be able to do) without
knowing what DateStyle is set to. What you're proposing above would
add even more hidden state to the protocol.

Perhaps we could add ParameterStatus support for these things, though.
I see your point that it's unlikely the client's desires will change
much over a session, so having to repeat the request with each query
might be overkill.

> The consequence for the protocol: Keep the text/binary distinction, but
> make it per-column in the result. For backward compatibility, the client
> can still choose between text and binary on a command-level basis, but we
> should move this to a session parameter, and if command and session
> settings are incompatible, one prevails or we signal an error.

I was actually envisioning that text and binary would become
interchangeable as far as the protocol is concerned: DataRow carries a
length and some bytes, and what's in the bytes is interpreted based on
format codes. So I don't see a need to think in terms of the formats
being classified as text and binary.

regards, tom lane