On Mon, Jul 30, 2018 at 10:31 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Melvin Davidson <melvin6...@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?* -- *Melvin Davidson* *Maj. Database & Exploration Specialist* *Universe Exploration Command – UXC* Employment by invitation only!
