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.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly