Both array and record binary recv functions require that the recv'd Oid
match the Oid of what the backend has deduced. We don't think this
behavior gets you very much. The backend apparently knows the Oid of a
composite or array elemtype, so if the sender chooses to send InvalidOid
why shouldn't that translate into the backend's idea of the Oid.
array_recv line 1204
element_type = pq_getmsgint(buf, sizeof(Oid));
if (element_type != spec_element_type)
{
/* XXX Can we allow taking the input element type in any cases? */
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("wrong element type")));
}
Why not?
element_type = pq_getmsgint(buf, sizeof(Oid));
if(element_type == InvalidOid) // use backend's oid
element_type = spec_element_type;
if (element_type != spec_element_type)
[snip...]
record_recv line 523 -- Same with composites
coltypoid = pq_getmsgint(buf, sizeof(Oid));
if(coltypoid == InvalidOid) // use backend's oid
coltypoid = column_type;
if (coltypoid != column_type)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("wrong data type: %u, expected %u",
coltypoid, column_type)));
If it is desired to have strict type checking, then the sender can still
send the Oid. In this case, if the Oid doesn't match the backend's an
error is raised (current behavior).
Without this change, a libpq client is forced to know the Oids of all
types within a composite and all types used with arrays. Currently,
there is no way for a libpq client to know the Oid of a composite. The
client would have to query them from the server or hard-code them.
Hard-coding is a bad idea unless you are using a built-in type. libpq
could have an API call:
PQlookupOid(PGconn *conn, char **type_names, Oid *oids, int count);
Oid oid[2];
char *types[] = {"public.type_a", "myschema.type_a"};
PQlookupOid(conn, types, 2, oid);
andrew & merlin
eSilo
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
