On Sunday, January 13, 2019 4:57:48 PM EST Tom Lane wrote:
> I also wonder why we'd allow RECORD but not RECORDARRAY.
That's by omission. There's no reason to refuse RECORDARRAY here for
the same reason why RECORD is accepted.
> More generally, why not any polymorphic type? [...] the
> fact that a record value is self-identifying as long as you know
> it's a record, whereas a random Datum is not a self-identifying
> member of the type class "anyelement", for instance.
Yes that's the reason. We allow "record" in coldeflist because it
only happens near a RangeFunction, and set-returning functions always do
"BlessTupleDesc", which means that RECORDOID data would always have an
associated TupleDesc and can be processed as a regular composite type.
Recursion is not an issue, since every instance would have a separate
TupleDesc even if the shape is the same.
> I feel a bit uncomfortable about defining the new flag to
> CheckAttributeNamesTypes as "allow_anonymous_records"; that
> seems pretty short-sighted and single-purpose, especially in
> view of there being no obvious reason why it shouldn't accept
> RECORDARRAY too. Maybe with a clearer explanation of the
> issues above, we could define that flag in a more on-point way.
I renamed it to "in_coldeflist", which seems like a clearer indication
that we are validating that, and not a regular table definition.
> BTW, it strikes me that maybe the reason ANYARRAY isn't insane
> to allow in pg_statistic has to do with arrays also being
> self-identifying members of that type class
That's true. Array data encode the OID of their element type, but that
only allows sending the data out, as subscripting or casting anyarray is
not allowed. There also seems to be no guarantee that the actual type
of the array doesn't change from row to row in such a scenario. Given
that, I think it would be best to keep anyarray restricted to the system
catalogs.
I attached the updated patch.
Elvis
