Tom Lane wrote:
>
> Peter Eisentraut <peter_e@gmx.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,
exceptthat 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.
