Re: pg_constraint.conincluding is useless

Stephen Frost <sfrost@snowman.net>

From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Teodor Sigaev <teodor@sigaev.ru>, Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Date: 2018-09-02T19:14:11Z
Lists: pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > This requires a catversion bump, for which it may seem a bit late;
> > however I think it's better to release pg11 without a useless catalog
> > column only to remove it in pg12 ...

Yeah, I really don't think we want to have another catalog column that
we end up wanting to remove later on, if we can avoid it..

> Catversion bumps during beta are routine.  If we had put out rc1
> I'd say it was too late, but we have not.

I agree that rc1 would be too late.  On the flip side, I don't think
we should really consider catversion bumps during beta to be 'routine'.

> If we do do a bump for beta4, I'd be strongly tempted to address the
> lack of a unique index for pg_constraint as well, cf
> https://www.postgresql.org/message-id/10110.1535907645@sss.pgh.pa.us

All that said, given that we've got two pretty good reasons for a
catversion bump, and one is to remove a useless column before it ever
gets in a release, I'm +1 for making both of these changes.

Thanks!

Stephen

Commits

  1. Remove pg_constraint.conincluding

  2. Indexes with INCLUDE columns and their support in B-tree