Re: Missing meta data information for bit and bit varying - Mailing list pgsql-odbc

I think the idea of the original function is good where for known types we have our answers without a query.  But I
agreethat 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
ofthe type we did not know about and finds the info via query and caches the results.  (maybe that would be two patches
toisolate 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@vmware.com]
Sent: Thursday, June 12, 2014 10:19 AM
To: Walter Couto; pgsql-odbc@postgresql.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
forthe 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
casefor 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
value255. 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
thevalue 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
thancheck 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
confidentialand privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you
arenot the intended recipient, please contact the sender by reply email and destroy all copies of the original
message.