From: | Chris Bitmead <chris(at)bitmead(dot)com> |
---|---|
To: | Postgres Hackers List <hackers(at)postgresql(dot)org> |
Subject: | Re: libpq / SQL3 |
Date: | 2000-07-09 04:51:21 |
Message-ID: | 396804C9.2A786042@bitmead.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Snow | 2000-07-09 05:37:13 | Unnexpected results using to_number() |
Previous Message | Tom Lane | 2000-07-08 23:02:37 | Re: SSL |