From a22712527a6057eb8adaa9dbadecf092eb27febc Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Mon, 21 Dec 2015 14:52:38 +0200 Subject: [PATCH] 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. --- pgtypes.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/pgtypes.c b/pgtypes.c index 167966f..c5c6beb 100644 --- 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; -- 2.39.5