libpq / SQL3

From: Chris Bitmead <chris(at)bitmead(dot)com>
To: Postgres Hackers List <hackers(at)postgreSQL(dot)org>
Subject: libpq / SQL3
Date: 2000-07-07 16:50:53
Message-ID: 39660A6D.3B60BD15@bitmead.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


I'm looking at implementing the SQL99 C interface, which looks more or
less reasonable. There are some annoyances however. The API to describe
the return result SQLDescribeCol takes a pointer to a SQLSMALLINT to
return the type of the returned column. There are a whole lot of #define
values in the standards document with specified values for each of the
standard types. This is annoying because an Oid is bigger than a
SQLSMALLINT, and the postgres oid values are not the same as the
standards #define values.

Now what it is tempting to do is to change the API to instead take a
pointer to a Oid, and redefine the #define values to the standard oid
values for postgres. However this would obviously be a change to the
API. Or I could define a new API, which kinda defeats the purpose of
using a standard API since the standard would become largely useless for
postgres users.

Any thoughts? I'm tempted to define a new datatype
typedef Oid SQLDATATYPE;
This is what the standard should have done IMHO. It would be one of
those minor incompatibilities that people trying to write portable code
could easily fix to be portable between implementations, simply by
defining this variable as a SQLDATATYPE instead of SQLSMALLINT.

Or I could go for a custom API. I guess it's probably all a bit of a
wasted argument since only postgres will have implemented the API. Maybe
we can set the standard?

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-07-07 16:52:29 Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...
Previous Message Tom Lane 2000-07-07 16:35:14 Re: Re: [HACKERS] Re: [SQL] MAX() of 0 records.