Re: libpq / SQL3

Tom Lane wrote:
>
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > 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.
>
> But there are no standard numbers for user-defined types, now are there?

Well the standard lists numbers for each type, with the comment in the
header
"sqlcli.h Header File for SQL CLI.
* The actual header file must contain at least the information
* specified here, except that the comments may vary."

So if you are pedantic I guess you have to use their numbers?? The other
problem as I said is that their type is a short, whereas Oid is a long,
so there is no guarantee it will fit. I guess the core types will fit
because they happen to be smaller than this.

> Might as well use the type OID for them.
>
> Adding another column to pg_type inside the backend is not too hard,
> but to transmit that data to the frontend in every query would mean
> an incompatible protocol change, which is a much greater amount of
> pain. I doubt it's worth it. Putting the translation table into
> SQLDescribeCol is no worse than having the ODBC driver do a similar
> translation, which no one has complained about in my recollection.

I agree.