Re: Transform groups (more FE/BE protocol issues) - Mailing list pgsql-interfaces
From | Tom Lane |
---|---|
Subject | Re: Transform groups (more FE/BE protocol issues) |
Date | |
Msg-id | 21371.1052182158@sss.pgh.pa.us Whole thread Raw |
In response to | Re: Transform groups (more FE/BE protocol issues) (Peter Eisentraut <peter_e@gmx.net>) |
List | pgsql-interfaces |
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.) 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
pgsql-interfaces by date: