binary array and record recv

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