Re: Missing meta data information for bit and bit varying

I think the idea of the original function is good where for known types we have our answers without a query. But I agree that we need some sort of query and a hash map to store types we don't know about.

So the fix is probably to add the known types we know are missing right now and then also add a code that takes the OID of the type we did not know about and finds the info via query and caches the results. (maybe that would be two patches to isolate the changes)

I'll see if I can get the project building and take a crack at adding this. Anyone have other ideas or comments?

Walter

-----Original Message-----
From: Heikki Linnakangas [mailto:hlinnakangas(at)vmware(dot)com]
Sent: Thursday, June 12, 2014 10:19 AM
To: Walter Couto; pgsql-odbc(at)postgresql(dot)org
Subject: Re: [ODBC] Missing meta data information for bit and bit varying

On 06/11/2014 11:50 PM, Walter Couto wrote:
> Have a table similar to the one below:
>
> CREATE TABLE bitstring_test
> (
> test integer NOT NULL,
> bit_col bit(47),
> bitvarying_col bit varying(47),
> PRIMARY KEY (test)
> )
>
> You can before a select * from the table above and observe what information is given back to you by the ODBC driver for the bit and bit varying colums:
>
>
> 1) Both bit_col and bitvarying_col return "unknown" for the type name (SQLColAttribute using SQL_DESC_TYPE_NAME). This appears to be due to the fact that in pgtypes.c the method pgtype_attr_to_name is missing the case for PG_TYPE_BIT and is missing the #define and case for bit varying(1562).
>
> 2) For bit_col, calls to SQLColAttribute passing either SQL_DESC_LENGTH or SQL_DESC_DISPLAY_SIZE both return the value 255. Which is not what the size is stated above but at least it is bigger :).
>
> 3) For bitvarying_col, calls to SQLColAttribute passing either SQL_DESC_LENGTH or SQL_DESC_DISPLAY_SIZE return the value 43. Which is not correct and smaller than what is stated above so this can cause problems. :(
>
> Any idea if I there is a way for me to avoid problem 3) as I can't tell from the type name what I am looking at.

The list of built-in types that the internal pgtype_attr_to_name() function knows about haven't been updated for a long time. At a quick glance, it's also seems to be missing all range and array types, for example.

Given that writing custom data types is a very prominent feature in PostgreSQL, it would be nice if we could do better than check against a hard-coded list of built-in functions. I think
SQLColAttribute(SQL_DESC_TYPE_NAME) should query the pg_type catalog to get the type name.

Patches are welcome..

- Heikki

CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.