From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Chris Bitmead <chris(at)bitmead(dot)com>, Postgres Hackers List <hackers(at)postgresql(dot)org> |
Subject: | Re: libpq / SQL3 |
Date: | 2000-07-08 02:56:06 |
Message-ID: | 23168.963024966@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
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
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2000-07-08 02:56:46 | Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios... |
Previous Message | Tom Lane | 2000-07-08 02:48:25 | Re: Something's not (de)compressing right... |