Обсуждение: Re: [GENERAL] express composite type literal as text

Eric Hanson <elhanson@gmail.com> writes:
> How do I express a composite type literal as text?

The rules are given in the manual ...

> I can't use the ROW() notation, because all values need to be represented
> as text over a REST api.  But I can't seem to get the text-based syntax to
> work:

> select * from on_hand where item='("fuzzy dice",42,1.99)';

> yeilds

> ERROR:  input of anonymous composite types is not implemented

That message isn't telling you that you've got a problem with the data
syntax, it's telling you that you need to cast the literal to a named
composite data type.  This works:

# select * from on_hand where item='("fuzzy dice",42,1.99)'::inventory_item;
          item          | count
------------------------+-------
 ("fuzzy dice",42,1.99) |  1000
(1 row)

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.

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 ...