Re: libpq / SQL3

Chris Bitmead writes:

> 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.

Then it seems we need to add a column to pg_type to keep track the
"sqltypeid" as an int2. It would be annoying but doable. The alternative
for the moment would be to hard-code the translation at the client side,
i.e., have SQLDescribeCol translate the oid it received to some standard
number, but that would have obvious problems with user-defined types.

> I'm tempted to define a new datatype
> typedef Oid SQLDATATYPE;
> This is what the standard should have done IMHO.

The standard doesn't require that system catalogs are implemented as
user-space tables, but equating types to oids would have effectively
imposed that requirement.

> 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?

I wonder. I doubt that they invented this API out of the blue. (Although
quite honestly it sometimes looks like it. Note how they religiously avoid
pointers everywhere.) It looks like a great goal to achieve though. Having
a standard as reference is always good. ("It is so because SQL says so."
"Your API might be nice, but ours is standard.")

Btw., I've been considering implementing this as a rather thin layer on
top of libpq, the idea being that those who want to write portable
applications can use SQL/CLI, and those who want to use Postgres-specific
features use libpq. I guess you'd rather completely replace libpq? I'd be
afraid of effectively abandoning libpq, with everything that's build upon
it.

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden