Re: [PATCH] Allow anonymous rowtypes in function return column definition

Elvis Pranskevichus <el(at)prans(dot)net> writes:
> On Sunday, January 13, 2019 4:57:48 PM EST Tom Lane wrote:
>> 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.

I still found this pretty disjointed. After a bit of thought I propose
the attached reformulation, which has the callers just tell the routines
which types to allow explicitly, with the justification comments living
at the call sites instead of within the routines.

One point that we hadn't really talked about is what happens when
CheckArrayTypes recurses. The existing logic is that it just passes
down the same restrictions it was told at the top level, and I kept
that here. Right now it hardly matters what we pass down, because
the base type of a domain or array can't be a pseudotype, and we
don't really expect to find one in a named composite type either.
The one case where it could matter is if someone tries to use
"pg_statistic" as a field's composite type: that would be allowed if
allow_system_table_mods and otherwise not. But it's not really
hard to imagine future additions where it would matter and it'd
be important to restrict things as we recurse down. I think this
formulation makes it easier to see what to do in such cases.

regards, tom lane