Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> 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.



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to