Re: SQL_DATA_AT_EXEC processing broken for large objects in nightly git

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: "Inoue, Hiroshi" <h-inoue(at)dream(dot)email(dot)ne(dot)jp>
Cc: pgsql-odbc(at)postgresql(dot)org
Subject: Re: SQL_DATA_AT_EXEC processing broken for large objects in nightly git
Date: 2015-12-21 12:58:57
Message-ID: 5677F791.10006@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

On 17/11/15 04:35, Inoue, Hiroshi wrote:
> Hi Heikki,
>
> The attached patch seems to fix all but I don't understand
> sqltype_to_bind_pgtype() well.
> Comments?

Ah, thanks, I see what the problem is now. I haven't looked at the
extra-transaction part yet, but the rest looks good to me, so I
committed my original patch and the sqltype_to_bind_pgtype() part of
your patch.

You must've figured this out already, but I'll summarize the issue for
the sake of the archives:

sqltype_to_bind_pgtype() was introduced in commit
1ccd04c70b8037b268eefcaae09ce131c8c33b59. Before that, query parameters
were always sent to the server as 'unknown', and the server deduced the
correct datatype. After that commit, we send a suitable PostgreSQL type
OID to the server, depending on the SQL_* type code that application
gave. For example, if you call SQLBindParameters(SQL_INTEGER), we send
the query parameter to the server as 'int4'. That fixes cases like
"SELECT '555' < ?", where it makes a big difference whether the server
treats the parameter as text or integer.

So when the application binds a parameter as SQL_LONGVARBINARY, we now
send it to the server as 'bytea', if ByteaAsLongVarBinary=1, or as 'lo'
otherwise. If you set ByteaAsLongVarBinary=1, the driver reports bytea
fields as SQL_LONGVARBINARY, so it makes sense that we do the same in
the other direction: when the application binds a parameter as
SQL_LONGVARBINARY, send it as 'bytea' to the server. But unfortunately,
it doesn't work if the column is in fact a large object.

Your patch reverts the behaviour of SQL_LONGVARBINARY parameters back to
sending them as 'unknown'. That seems reasonable. It would be nice to
pass a datatype to the server, but there is no way to specify "bytea or
a large object". If we choose either one, the other case will be wrong.
Sending SQL_LONGVARBINARY parameters as 'unknown' should be OK in
practice, there is not much danger for "SELECT '555' < ?" kind of
ambiguity with binary parameters.

- Heikki

In response to

Browse pgsql-odbc by date

  From Date Subject
Next Message Ondrej Dzivy Balucha 2015-12-21 13:27:36 query timeout
Previous Message Adrian Klaver 2015-12-13 14:17:16 Re: Installing odbc-driver on client