On Sun, Feb 22, 2015 at 12:56 PM, Tom Lane <t...@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. Thanks, Eric
