Length of bytea - Mailing list pgsql-odbc

From Daniel Homerick
Subject Length of bytea
Date
Msg-id 9570C4F8577FC041964C389777970D7744BC2613B4@KITT.sensingsystems.com
Whole thread Raw
Responses Re: Length of bytea  ("Inoue, Hiroshi" <inoue@tpf.co.jp>)
List pgsql-odbc

When I use the SQLColAttribute function to get the either the SQL_DESC_LENGTH or SQL_DESC_OCTET_LENGTH attribute, a bytea column reports the “Max Varchar”  configuration value (255 by default), even when the actual data length is longer. This appears to be the case when the “Unknown Sizes” configuration option is at either the default “Maximum” value, or the “Don’t Know” option.

 

I ran into this as a problem when trying to determine an appropriate buffer size for use by SQLBindCol. When I would naively use the reported size for my buffer, a segfault was never far behind.

In my case, I can’t particularly trust that the system will always be set up with the “Unknown Sizes” config option set to “Longest”. And since the “Max Varchar” is a user configurable value, I can’t just special case my code to treat 255 as a magic value. With the potential for crashing my app if the ODBC isn’t configured as expected, I’m currently thinking that I’ll need to always use SQLGetData over SQLBindCol when using Postgres and dealing with bytea columns.

 

Is there some other function or attribute I should be using in order to determine a bytea column’s actual length?

Alternatively, is there a function I can call to get the “Max Varchar” value, so that I can use it to compare (and not trust the value if it matches)?

Are there other approaches that I should explore instead?

 

As an aside, psqlODBC’s behavior here doesn’t really seem to jive with Microsoft’s ODBC documentation:
http://msdn.microsoft.com/en-us/library/ms713558(v=vs.85).aspx

 

Thanks!

- Dan

 

Using:

psqlODBC_x64 09.02.0100 (Unicode)

PostgreSQL 9.2 (x64)

Windows 7

 

 

 

pgsql-odbc by date:

Previous
From: PG User
Date:
Subject: Re: support for keep alive option
Next
From: "Inoue, Hiroshi"
Date:
Subject: Re: psqlodbcw.so vs libodbcpsql.so