Re: [BUGS] BUG #11767: ODBC driver bug when fetching constant string columns

On Fri, Oct 24, 2014 at 9:36 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> On Wed, Oct 22, 2014 at 11:22 PM, <keyurgovande(at)gmail(dot)com> wrote:
> > The following bug has been logged on the website:
> >
> > Bug reference: 11767
> > Logged by: Keyur Govande
> > Email address: keyurgovande(at)gmail(dot)com
> > PostgreSQL version: 9.0.3
> You should update to 9.0.18, you are 3.5 years of bug fixes.
>

Ah I apologize, I chose the wrong version in the bug report dropdown. This
bug was observed with the latest driver: psqlodbc-09.03.0300 connecting to
a Postgres server 9.1.14.

>
> > If we run a SELECT statement like: SELECT id, varchar_col, date_col,
> 'random
> > string' as random;
> > via ODBC, then the last column comes back as junk into PHP.
> >
> > In PHP we use the SQL_DESC_OCTET_LENGTH to figure out how many bytes to
> > allocate. But for that column, SQL_DESC_OCTET_LENGTH returns 0 and we
> don't
> > allocate enough space.
> >
> > The driver issue seems to be that when SQLColAttributes() is called with
> > SQL_COLUMN_TYPE for column 'random', it returns SQL_VARCHAR even though
> the
> > PG type is PG_TYPE_UNKNOWN. The promotion is happening here:
> >
> http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=blob;f=pgtypes.c;h=4ce7636b69d371d9f511d492c68013f070e3b32a;hb=HEAD#l665
> >
> > I think the same promotion needs to happen when fetching octet-length
> here:
> >
> http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=blob;f=pgtypes.c;h=4ce7636b69d371d9f511d492c68013f070e3b32a;hb=HEAD#l1275
> >
> > Thoughts? This is not a problem when using the Vertica ODBC driver for
> > example.
> >
> > A temporary workaround is to use a cast thusly: SELECT id, varchar_col,
> > date_col, varchar 'random string' as random;
> > This was reported to the PHP project (
> https://bugs.php.net/bug.php?id=68087)
> > but it seems like a Postgres ODBC driver bug.
> pgsql-odbc is more adapted for a bug report on the ODBC driver. I am
> moving the thread there.
> --
> Michael
>