Re: BUG #18660: information_schema.columns.ordinal_position has gaps when primary key columns are dropped

On 2024-10-17 16:19 +0200, Tom Lane wrote:
> PG Bug reporting form <noreply(at)postgresql(dot)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
> > ))

Same for information_schema.attributes.ordinal_position, although I
don't know if that defines an equivalent constraint.

> Hm. I'm not sure if it's worth making that view even slower in order
> to clean up the numbering.

But then we should at least fix the docs which say that the count starts
at 1.

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

I don't think so. That sub-select only returns NULL when looking up
that empty table. That entire CHECK expression with "ALL" will happily
return true.

regress=# create table t0 ();
CREATE TABLE
regress=# select max(ordinal_position) - count(*) from information_schema.columns where table_name = 't0';
?column?
----------
<NULL>
(1 row)

regress=# select 0 = all (select max(ordinal_position) - count(*) from information_schema.columns group by table_catalog, table_schema, table_name);
?column?
----------
t
(1 row)

--
Erik