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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: lukas(dot)eder(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18660: information_schema.columns.ordinal_position has gaps when primary key columns are dropped
Date: 2024-10-17 14:19:15
Message-ID: 650059.1729174755@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Erik Wienhold 2024-10-17 15:02:35 Re: BUG #18660: information_schema.columns.ordinal_position has gaps when primary key columns are dropped
Previous Message PG Bug reporting form 2024-10-17 12:56:39 BUG #18662: ORDER BY after GROUPING SETS does not order correctly for certain WHERE condition