Eric Hanson <elhanson@gmail.com> writes:
> On Sun, Feb 22, 2015 at 11:47 AM, Tom Lane <tgl@sss.pgh.pa.us> 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