Re: [GENERAL] express composite type literal as text

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