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