On Sun, Feb 22, 2015 at 12:56 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Well, it's an unimplemented feature anyway. I poked into it and noticed
that the equivalent case for arrays works, because that operator is
"anyarray = anyarray". enforce_generic_type_consistency() observes that
we have an unknown literal that's going to be passed to an anyarray
function argument, so it resolves "anyarray" as the actual array type
determined from the other anyarray argument position.
There's no corresponding behavior for RECORD, because RECORD is not
treated as a polymorphic type for this purpose -- in particular, there is
no built-in assumption that the two arguments passed to record_eq(record,
record) should be the same record type. (And, indeed, it looks like
record_eq goes to some effort to cope with them not being identical;
this may be essential to make dropped-column cases work desirably.)
Conceivably we could invent an ANYRECORD polymorphic type, extend the
polymorphic type logic to deal with that, and redefine record_eq as taking
(anyrecord, anyrecord). However that'd likely break some scenarios along
with fixing this one. It'd require some research to figure out what's
the least painful fix. In any case, anything involving a new datatype is
certainly not going to be a back-patchable bug fix.
Given that it's worked like this pretty much forever, and there have been
few complaints, it's probably not going to get to the front of anyone's
to-do list real soon ...
Ok. Thanks for the info. I like the ANYRECORD idea.
As for the behavior, consider me logging one complaint. :) The consequence is that you can't use composite types in a REST interface or any other string-based interface, unless the POST handler look up the type of all columns and checks for the special case, to add the explicit cast. It adds a lot of overhead that is 99% unnecessary.
Thanks,
Eric
