Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Arrays of Complex Types

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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

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

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

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-04-09 01:53:46
Subject: Re: [HACKERS] Arrays of Complex Types
Previous:From: Andrew DunstanDate: 2007-04-09 00:35:53
Subject: Re: [HACKERS] Arrays of Complex Types

pgsql-patches by date

Next:From: Bruce MomjianDate: 2007-04-09 01:46:21
Subject: Re: [PATCHES] Fix misleading references to columns in GRANT/REVOKE summaries
Previous:From: Andrew DunstanDate: 2007-04-09 00:35:53
Subject: Re: [HACKERS] Arrays of Complex Types

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group