libpq / SQL3 - Mailing list pgsql-hackers

From Chris Bitmead
Subject libpq / SQL3
Date
Msg-id 39660A6D.3B60BD15@bitmead.com
Whole thread Raw
Responses Re: libpq / SQL3  (Peter Eisentraut <peter_e@gmx.net>)
List 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?


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] Re: Re: [SQL] MAX() of 0 records.
Next
From: Tom Lane
Date:
Subject: Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...