Re: libpq / SQL3

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?

In response to

Responses

Browse pgsql-hackers by date

  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