Re: remove pg_class.relhaspkey

On Mon, Feb 26, 2018 at 12:45:48AM -0500, Tom Lane wrote:
> Michael Paquier <michael(at)paquier(dot)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)?

As far as I looked at things. Those clients rely on how optimistic
relhaspkey is. In short, if it is set to true, there can be primary
key definitions. If set to false, then it is sure that no primary key
definition can be found. If the flag is true, then those clients just
do an extra lookup on pg_index with indisprimary. I think that this
just complicates the code involved though. If looking for primary keys
it is way better to just scan directly pg_index.

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

The only breakage I could imagine here is an application which thinks
relhaspkey set to true implies that a primary key *has* to be present.
I have to admit that I have not found such a case. Still I would not be
surprised if there are such applications unaware of being broken,
particularly plpgsql functions.
--
Michael