From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | David Fetter <david(at)fetter(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Arrays of Complex Types |
Date: | 2007-04-09 00:41:06 |
Message-ID: | 12857.1176079266@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2007-04-09 01:53:46 | Re: [HACKERS] Arrays of Complex Types |
Previous Message | Andrew Dunstan | 2007-04-09 00:35:53 | Re: [HACKERS] Arrays of Complex Types |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-04-09 01:46:21 | Re: [PATCHES] Fix misleading references to columns in GRANT/REVOKE summaries |
Previous Message | Andrew Dunstan | 2007-04-09 00:35:53 | Re: [HACKERS] Arrays of Complex Types |