Chris Bitmead <chris@bitmead.com> writes:
> Tom Lane wrote:
>> But there are no standard numbers for user-defined types, now are there?
> Well the standard lists numbers for each type, ...
> So if you are pedantic I guess you have to use their numbers?? The other
> problem as I said is that their type is a short, whereas Oid is a long,
> so there is no guarantee it will fit.
I'd read that as saying that you have to use their numbers for the types
that are called out in the standard. But user-defined types cannot be
called out in the standard (or have they standardized prescience as well?)
so we're on our own about how to represent those.
>> Might as well use the type OID for them.
I had second thoughts about this, because one of the things I think will
be happening in the not-too-distant future is that we'll be offering a
configure-time choice about whether OID is 4 or 8 bytes (that is, long
or long long). I suspect it'd be a bad idea to have core aspects of
libpq's API change in a binary-incompatible fashion depending on a
server configuration choice.
What might be the best bet is for this translation function to return
"short" as in the spec, with the spec-defined values for the datatypes
known to the spec, and a single "UNKNOWN" value for everything else.
Apps that need to tell the difference among user-defined types could
look at either the type OID or the type name, taking a binary-
compatibility risk if they insist on using the OID in binary form
(as long as they treat it as an ASCII string they probably aren't
affected by 4 vs 8 bytes...) But a bog-standard app would never look
at either, because it's only using bog-standard datatypes, no?
regards, tom lane
