Re: remove pg_class.relhaspkey

On Sat, Feb 24, 2018 at 10:21:44PM -0500, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> > pg_class.relhaspkey doesn't seem to be used or useful for anything, so
> > can we remove it? See attached patch.
>
> We've discussed that at least twice before, and not pulled the trigger
> for fear of breaking client code.
>
> https://www.postgresql.org/message-id/flat/CAA-aLv7sszmU%2BFz-xLo6cOiASUiX0mCRwAMF2FB%3D2j-5MKqb%2BA%40mail.gmail.com
> https://www.postgresql.org/message-id/flat/20140317185255.20724.49675%40wrigleys.postgresql.org
>
> Not sure that the situation has changed any since then ... it still
> comes down to whether we want an API break for client code.

I would be of the opinion to drop them. Even if some client code rely
on this information, it means that they also rely on some information
which may be incorrect if those are not updated when they should be for
certain DDL combinations. And in my opinion that's bad. It seems to me
that if we would want to do some cleanup, this should happen for all the
flags that are updated in a lazy fashion. For most of them, it would be
easy enough to replace them by subqueries which scan other catalog
information for correct and actually up-to-date information. So in this
category enter as well relhassubclass, relhastriggers and relhasrules.

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
So the answer is yes, there would be code breakages if those get
removed. Still I would imagine that such applications ought to use
subquery patterns and not rely on the existing flags, as this causes in
the worst case extra round trips between the server and the client as
the client is unsure if the information is up-to-date or not.
--
Michael