Re: [HACKERS] Arrays of Complex Types

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> How would we do that? Not create the array types in bootstrap mode? Or
>> just special-case pg_statistic?
>>
>
> Not generate them in bootstrap mode works for me. IIRC, there's code
> somewhere in there that allows anyarray to pass as a column type in
> bootstrap mode, so that seems to fit ...
>
>
>

OK, summarising what looks to me like a consensus position, ISTM the
plan could be:

. fix makeArrayTypeName() or similar to make it try harder to generate a
unique non-clashing name
. remove the existing "62 instead of 63" name length restrictions
. autogenerate array types for all explicitly or implicitly created
composite types other than for system catalog objects.
. defer for the present any consideration of a "CREATE TYPE foo AS ARRAY
..." command.

Regarding catalog objects, we might have to try a little harder than
just not generating in bootstrap mode - IIRC we generate system views
(including pg_stats) in non-bootstrap mode. Maybe we just need to exempt
anything in the pg_catalog namespace. What would happen if a user
created a view over pg_statistic? Should the test be to avoid arrays for
things that depend on the catalogs? Or maybe we should go to the heart
of the problem and simply check for pseudo-types directly.

cheers

andrew