Re: [HACKERS] Arrays of Complex Types

On Mon, Apr 09, 2007 at 10:40:49AM -0400, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > 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?
>
> Nothing:
>
> regression=# create view vvv as select * from pg_statistic;
> ERROR: column "stavalues1" has pseudo-type anyarray
>
> which means we do have an issue for the pg_stats view. Now that I look
> instead of guessing, the existing test in CheckAttributeType is not on
> bootstrap mode but standalone mode:
>
> /* Special hack for pg_statistic: allow ANYARRAY during initdb */
> if (atttypid != ANYARRAYOID || IsUnderPostmaster)
> ereport(ERROR,
> (errcode(ERRCODE_INVALID_TABLE_DEFINITION),
> errmsg("column \"%s\" has pseudo-type %s",
> attname, format_type_be(atttypid))));
>
> so for consistency we should use the same condition to suppress types
> for system catalogs.

Groovy :)

> > Or maybe we should go to the heart
> > of the problem and simply check for pseudo-types directly.
>
> Actually we may have an issue already:
>
> regression=# create table zzz (f1 pg_statistic);
> CREATE TABLE
>
> I couldn't make it misbehave in a short amount of trying:
>
> regression=# insert into zzz values(row(0,0,0,0,0,0,0,0,0,0,0,0,0,array[1,2],null,null,null,array[12,13],null,null,null));
> ERROR: ROW() column has type integer[] instead of type anyarray
>
> but I don't feel comfortable about this at all. Maybe
> CheckAttributeType should be made to recurse into composite columns.

That'd be great :)

Cheers,
D
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate