Eric Hanson <elhanson@xxxxxxxxx> writes: > On Sun, Feb 22, 2015 at 11:47 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> Now, I'm not too sure *why* it's making you do that --- seems like the >> default assumption ought to be that the literal is the same type as >> the variable it's being compared to. Perhaps there's a bug in there, >> or perhaps there's no easy way to avoid this requirement. But that's >> what the requirement is today. > Got it. Ok, I'm reporting this as a bug. Is this a bug? Being able to > always express literals as text is a really valuable assumption to be able > to rely on. 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 ... regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
