Skip site navigation (1) Skip section navigation (2)

Re: segfault in SQLSpecialColumns when table name is null string

From: Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>
To: Lionel Elie Mamane <lionel(at)mamane(dot)lu>
Cc: Terrence Enger <tenger(at)iseries-guru(dot)com>, pgsql-odbc(at)postgresql(dot)org
Subject: Re: segfault in SQLSpecialColumns when table name is null string
Date: 2012-07-14 21:50:27
Message-ID: 5001E9A3.6070707@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-odbc
Hi、

(2012/07/10 23:27), Lionel Elie Mamane wrote:
> On Tue, Jul 10, 2012 at 08:22:52AM -0400, Terrence Enger wrote:
>
>> Working with PostgreSQL version 8.4.12-0ubuntu11.04 and with ODBC
>> driver versions 1:08.03.0200-1.2 (supplied with ubuntu-natty (11.04))
>> and pgsqlodbc-09.01.0100 (built locally), I have managed to provoke a
>> segfault by calling SQLSpecialColumns with a null string for the table
>> name.  This call is, of course, a strange thing to do, and I cannot
>> imagine any good result.  Still, a segfault seems a disproportionate
>> punishment for doing something silly.
>
> Also, the ultimate reason for this "strange thing" is that
>
>   SQLColAttribute( (SQLHANDLE) 0x1ec7850,
>                    (SQLUSMALLINT) 1,
>                    (SQLUSMALLINT) 15,
>                    (SQLPOINTER) 0x1eb2640,
>                    128,
>                    (SQLSMALLINT *) 0x7fffffff97de,
>                    NULL);
>
> where 15 == SQL_DESC_TABLE_NAME == SQL_COLUMN_TABLE_NAME
> returns (writes at 0x1eb2640) an empty string for this query:
>
>   SELECT "Num" "Numero", "data" FROM "foo"."Table1"

What is your environment e.g. the version of your PG server
or the version of your psqlodbc?

regards,
Hiroshi Inoue


In response to

Responses

pgsql-odbc by date

Next:From: Lionel Elie MamaneDate: 2012-07-15 05:02:11
Subject: Re: segfault in SQLSpecialColumns when table name is null string
Previous:From: Nelson Manuel MarquesDate: 2012-07-12 19:11:02
Subject: Questions regarding versioning

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group