Alvaro Herrera <[EMAIL PROTECTED]> writes: > Hmm, I question the usefulness of automatically creating array types for > all relation types that are created -- the catalog bloat seems a bit too > much. An array of pg_autovacuum for example, does that make sense?
Not only that, it won't even work for pg_statistic, which has got a special kluge to allow anyarray in a place where it usually mustn't go. > I'm not sure what was the reaction to having an "CREATE TYPE foo ARRAY > OF bar" command of some kind? I think this was discussed but not > explicitely rejected, or was it? I think this is a much better idea than automatically creating a pile of usually-useless types. In the long run maybe we should even migrate to the assumption that array types aren't automatically created? If we think this way, it changes the ground rules for Andrew's question about whether an array type ought to be affected by ALTER TYPE SET SCHEMA on its base type --- it starts to look more like an independent entity than an auxiliary component. I'm not really sure which answer I like better. One point here is that currently the system depends on the naming convention "foo is named _foo" to be able to find the array type from the base type. The syntax you suggest would break that. We could fix it by adding More Stuff to pg_type, but I wonder whether it's worth it, compared to say CREATE ARRAY TYPE FOR foo Also, at the moment ALTER TYPE SET SCHEMA is certainly broken because it destroys this naming convention ... we either abandon the convention or fix SET SCHEMA. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend