Re: remove pg_class.relhaspkey - Mailing list pgsql-hackers

From Tom Lane
Subject Re: remove pg_class.relhaspkey
Date
Msg-id 27703.1519623948@sss.pgh.pa.us
Whole thread Raw
In response to Re: remove pg_class.relhaspkey  (Michael Paquier <michael@paquier.xyz>)
Responses Re: remove pg_class.relhaspkey  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Sat, Feb 24, 2018 at 10:21:44PM -0500, Tom Lane wrote:
>> We've discussed that at least twice before, and not pulled the trigger
>> for fear of breaking client code.

> Speaking of which, I have looked at where relhaspkey is being used.  And
> there are a couple of things using it:
> - Greenplum has a consistency checker tool using it.
> - https://github.com/no0p/pgsampler
> - https://searchcode.com/codesearch/view/54937539/
> - http://codegist.net/code/postgres%20drop%20tables/
> -
https://hackage.haskell.org/package/relational-schemas-0.1.3.4/src/src/Database/Relational/Schema/PgCatalog/PgClass.hs

Thanks for poking around.  Did you happen to notice how many of these
clients are taking pains to deal with the existing inaccuracy of
relhaspkey (ie, that it remains set after the pkey has been dropped)?

I think there's possibly an argument that relhaspkey should be dropped
because it's an attractive nuisance, encouraging clients to assume
more than they should about what it means.  But we don't have a lot
of evidence for such an argument right now.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] SERIALIZABLE with parallel query
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: [bug fix] pg_rewind takes long time because it mistakenly copiesdata files