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