Thread

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

Erik Wienhold <ewie@ewie.name> — 2024-10-17T15:02:35Z

On 2024-10-17 16:19 +0200, Tom Lane wrote:
> 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 
> > ))

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