Let the server decide if SQL_LONGVARBINARY means a bytea or large object.

This reverts the behaviour of SQL_LONGVARBINARY parameters to the way it was
before commit 1ccd04c70b8037b268eefcaae09ce131c8c33b59. We can't reliably
guess in the driver whether the parameters should be sent to the server
as 'bytea' or as a large object, so send it as 'unknown' and let the server
decide.

Diagnosis and original patch by Hiroshi Inoue, I only added the comment.

diff --git a/pgtypes.c b/pgtypes.c
index 167966f0c28dac374407ca2c7968322683baaf97..c5c6beb55cec6adc9d55fe07ca8adc983017fa64 100644 (file)
--- a/pgtypes.c
+++ b/pgtypes.c
@@ -1258,6 +1258,19 @@ sqltype_to_bind_pgtype(const ConnectionClass *conn, SQLSMALLINT fSqlType)
            pgType = PG_TYPE_BYTEA;
            break;
 
+       case SQL_LONGVARBINARY:
+           /*
+            * SQL_LONGVARBINARY could mean a large object, but it could also
+            * mean bytea, in particular with ByteaAsLongVarBinary=1. With
+            * large binary parameters, there isn't much danger of confusing
+            * the datatype in practice - you typically just INSERT them
+            * into a table or UPDATE them, and don't apply any operators to
+            * them. So instead of trying to guess whether this is a 'bytea'
+            * or large object, let the server decide.
+            */
+           pgType = 0;
+           break;
+
        case SQL_BIT:
            pgType = ci->drivers.bools_as_char ? PG_TYPE_CHAR : PG_TYPE_BOOL;
            break;
@@ -1285,13 +1298,6 @@ sqltype_to_bind_pgtype(const ConnectionClass *conn, SQLSMALLINT fSqlType)
            pgType = PG_TYPE_INT4;
            break;
 
-       case SQL_LONGVARBINARY:
-           if (ci->bytea_as_longvarbinary)
-               pgType = PG_TYPE_BYTEA;
-           else
-               pgType = conn->lobj_type;
-           break;
-
        case SQL_REAL:
            pgType = PG_TYPE_FLOAT4;
            break;