Andrew Dunstan <[EMAIL PROTECTED]> 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.

> 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.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to