Re: BUG #18660: information_schema.columns.ordinal_position has gaps when primary key columns are dropped
От | Tom Lane |
---|---|
Тема | Re: BUG #18660: information_schema.columns.ordinal_position has gaps when primary key columns are dropped |
Дата | |
Msg-id | 650059.1729174755@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18660: information_schema.columns.ordinal_position has gaps when primary key columns are dropped (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #18660: information_schema.columns.ordinal_position has gaps when primary key columns are dropped
|
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > [ information_schema.columns.ordinal_position is just a copy of attnum ] > This is against the SQL standard specification of the > information_schema.columns.ordinal_position column, which has a constraint > as follows: > CONSTRAINT COLUMNS_ORDINAL_POSITION_CONTIGUOUS_CHECK CHECK (0 = ALL ( > SELECT MAX(ORDINAL_POSITION) - COUNT(*) > FROM COLUMNS > GROUP BY > TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME > )) Hm. I'm not sure if it's worth making that view even slower in order to clean up the numbering. Just as an aside, we'd still be violating the letter of this constraint, because for a zero-column table the sub-select will produce NULL not 0. If we ever complete the fabled project to split up logical and physical attnums, we would presumably be able to fix this without slowing down the view, since we'd want it to report logical attnums anyway. I don't have high hopes for that happening though ... regards, tom lane
В списке pgsql-bugs по дате отправления: