Tom Lane wrote:
> 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?
I agree, but perhaps for different reasons. I don't see any other
choice.
I'm making good progress on implementing the SQL99, but it is a lot
trickier than I thought. libpq is cruftier than meets the eye.
Can anybody (i.e Peter :) provide any insight on how the SQL99 API
handles variable length datatypes where you don't know the length in a
particular tuple in advance?