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.




---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to