Re: [HACKERS] Arrays of Complex Types

Andrew Dunstan <andrew@dunslane.net> writes:
> I'm slightly inclined to agree with David that the danger of catalog
> bloat isn't that great, and might not justify the extra work that some
> sort of explicit array creation would involve (e.g. changes in grammar,
> pg_dump), as long as we are agreed that we don't want array types ever
> to have their own user definable names or settable namespace.

I did some tests just now to determine the total number of catalog
entries associated with a simple table definition.  Assuming it has
N user columns of built-in types (hence not requiring pg_depend entries
for the datatypes), I count

1 pg_class entry for the table itself
1 pg_type entry for the rowtype
N + 6 pg_attribute entries for the user and system columns
2 pg_depend entries (type -> table and table -> namespace)
2 pg_shdepend entries (ownership of table and type)

Of course this goes up *fast* if you need a toast table, indexes,
constraints, etc, but that's the irreducible minimum.

Generating an array rowtype would add three more catalog entries to this
(the array pg_type entry, a pg_depend arraytype->rowtype link, and
another pg_shdepend entry), which isn't a huge percentage overhead.
Obviously if we wanted to trim some fat here, getting rid of the
redundant pg_attribute entries for system columns would be the first
place to look.

Based on this, I withdraw my efficiency concern about generating
rowtypes for all user tables.  I do, however, still object to generating
them for system tables.  In particular an array type for pg_statistic
will actively Not Work and probably constitute a security hole, because
of the "anyarray" hack we use there.

BTW, I just noticed that we currently create array types with AUTO
dependencies on their element type, meaning that you can drop them
separately:

regression=# create type fooey as enum ('a','b');
CREATE TYPE
regression=# drop type _fooey;
DROP TYPE

Is this a bad idea?  If we made the dependency INTERNAL then the
system would refuse the drop above.  I think we would have to do
that if we wanted to add the base->array link I suggested, because
otherwise this drop would leave a dangling pointer in pg_type.

            regards, tom lane