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?
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)
errmsg("column \"%s\" has pseudo-type %s",
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);
I couldn't make it misbehave in a short amount of trying:
regression=# insert into zzz
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 3: Have you checked our extensive FAQ?