I wrote:
>
> 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.
>
>
I've been working on David's patch and done the following:
. inhibit creation of array types for composites during initdb
. some bug fixes
. have CheckAttributeType recurse into composite types, so you can no
longer create a table/type with a composite field which contains a
pseudo-type column (like pg_statistic)
However, there are still some oddities. For example, a change to or
removal of the base type affects the array type, but the array type can
be directly operated on (e.g. alter type _aa set schema foo ). I'm
inclined to say we should prevent direct operations on array types, and
they should live or die by their parent types.
Thoughts?
cheers
andrew