On Mon, Jul 30, 2018 at 10:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Melvin Davidson <melvin6925@gmail.com> writes: > In the release notes for Version 11 Beta, under changes, I see these scary > remarks: > Remove relhaspkey column from system table pg_class (Peter Eisentraut) > Applications needing to check for a primary key should consult pg_index. > > That absolutely breaks my code (and I'm guessing others), as I have a cron > job that checks for tables that were created with no pkey.
Well, I'd say your code was broken anyway, because it has never been the case that relhaspkey meant that the table *currently* has a primary key. We got rid of it on the grounds that its semantics were too squishy to be useful.
What you want is something like
select relname from pg_class c where relkind = 'r' and not exists (select 1 from pg_index where indrelid = c.oid and indisprimary);
which will give the right answer in all PG versions.
regards, tom lane
it has never been the case that relhaspkey meant that the table *currently* has a primary key.
Tom,
>it has never been the case that relhaspkey meant that the table *currently* has a primary key.
That is a poor excuse, because that is exactly what I am looking for!
squishy semantics or not, dropping columns from system catalogs is ridiculous.
It appears to me that the developers are going rogue. Why should I, and others,
I have to change my code ( which absolutely works ), simply because the developers
feel it's ok to drop columns from system catalogs based on semantics?