Re: libpq / SQL3

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

That occured to me, but it doesn't seem worth cluttering up the back-end
to achieve.

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

For user-defined types, you're out of luck anyway as far as strictly
following the standard.

I think what you're saying is strictly follow the standard anyway. I
guess you're right, it's just annoying when the standard is slightly
lame but could be fixed with some ever-so subtle changes.

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

What I'm saying is that if the standard allowed for an SQLDATATYPE type,
whose exact type is implementation-defined, then implementations could
choose without affecting portablility.

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

Yes that is strange. I started off by defining various types as
structures thinking that all those SQLSHORTINT's everywhere were either
suggestions, or put there because they didn't have an idea of what the
implementation might do. Later I realised that maybe they really mean
them to be SHORTINTS, and I wonder whether I should change them back or
whether the client doesn't need to know. Looks like I'll change them
back I guess to be really strict about it.

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

That would be worth considering, except that part of the idea of me
going to the new API is to avoid some of the annoyances of libpq such as
the non-streaming nature of it. Maybe when everyone is comfortable with
the stability of the new library then libpq can be redone in terms of
SQL3? It would be pretty easy I think.

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