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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
