On Sun, Feb 22, 2015 at 12:56 PM, Tom Lane <tgl@sss.pgh.pa.us> 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.