Re: libpq / SQL3 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: libpq / SQL3
Date
Msg-id 23168.963024966@sss.pgh.pa.us
Whole thread Raw
In response to Re: libpq / SQL3  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
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?
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Something's not (de)compressing right...
Next
From: Philip Warner
Date:
Subject: Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...