SQLDescribeCol returning size 0 on bytea column if bytea as LO is enabled

[JacoboSanchez]

When I prepare a select on a table with a bytea column and execute the SQLDescribeCol column I get a -3 type (VARBINARY) and size 255. However with bytea active I get 0 size.

The SQLDEscribeCol documentation states that 0 is a valid value for sizes that can not be determined. However it seems a bit inconsistent the difference between VARBINARY and LONGVARBINARY. Is this expected?

Test on bytea column describe with default configuration

odbct32w        68bc-95dc	EXIT  SQLDescribeColW  with return code 0 (SQL_SUCCESS)
		HSTMT               0x0000000006EC28D0
		UWORD                        2 
		WCHAR *             0x000000000051EA20 [      11] "binary_data"
		SWORD                      600 
		SWORD *             0x00000000004F6D90 (11)
		SWORD *             0x0000000000576E20 (-3) <<< SQL_VARBINARY
		SQLULEN *           0x0000000000576E50 (255)  <<< SIZE 255
		SWORD *             0x0000000000576E80 (0)
		SWORD *             0x0000000000576EB0 (1)

mylog output:

38364-13.412] results.c[PGAPI_DescribeCol]369: PARSE: fieldtype=17, col_name='binary_data', column_size=255
[38364-13.412] results.c[PGAPI_DescribeCol]380: col 1 fieldname = 'binary_data'
[38364-13.412] results.c[PGAPI_DescribeCol]381: col 1 fieldtype = 17
[38364-13.412] results.c[PGAPI_DescribeCol]382: col 1 column_size = 255
[38364-13.412] results.c[PGAPI_DescribeCol]415: col 1 *pfSqlType = -3
[38364-13.412] results.c[PGAPI_DescribeCol]428: Col: col 1  *pcbColDef = 255
[38364-13.412] results.c[PGAPI_DescribeCol]440: col 1  *pibScale = 0
[38364-13.412] results.c[PGAPI_DescribeCol]453: col 1  *pfNullable = 1

However when I enable "bytea as LO":

odbct32w        68bc-95dc	EXIT  SQLDescribeColW  with return code 0 (SQL_SUCCESS)
		HSTMT               0x0000000006ECAD50
		UWORD                        2 
		WCHAR *             0x0000000000577590 [      11] "binary_data"
		SWORD                      600 
		SWORD *             0x00000000004F6D90 (11)
		SWORD *             0x0000000000576E20 (-4) <<<  SQL_LONGVARBINARY
		SQLULEN *           0x0000000000576E50 (0) <<<  SIZE IS 0
		SWORD *             0x0000000000576E80 (0)
		SWORD *             0x0000000000576EB0 (1)

mylog output:

[38364-28.194] results.c[PGAPI_DescribeCol]369: PARSE: fieldtype=17, col_name='binary_data', column_size=-4
[38364-28.194] results.c[PGAPI_DescribeCol]380: col 1 fieldname = 'binary_data'
[38364-28.194] results.c[PGAPI_DescribeCol]381: col 1 fieldtype = 17
[38364-28.194] results.c[PGAPI_DescribeCol]382: col 1 column_size = -4
[38364-28.194] results.c[PGAPI_DescribeCol]415: col 1 *pfSqlType = -4
[38364-28.194] results.c[PGAPI_DescribeCol]428: Col: col 1  *pcbColDef = 0
[38364-28.194] results.c[PGAPI_DescribeCol]440: col 1  *pibScale = 0
[38364-28.194] results.c[PGAPI_DescribeCol]453: col 1  *pfNullable = 1

[davecramer]

Do you have the table definitions ?

[JacoboSanchez]

This is the output of pgadmin generating the create table script. Any table with a bytea column and preparing a select on it should work. My test was preparing a select * and describing column 2

CREATE TABLE IF NOT EXISTS public.test_binary
(
    id integer,
    binary_data bytea,
    description character varying(255) COLLATE pg_catalog."default"
)

[davecramer]

interesting
Even 255 is potentially wrong for bytea.