About the CREATE TABLE LIKE indexes vs constraints issue

In connection with the operator-exclusion patch,
Brendan Jurd <direvus(at)gmail(dot)com> wrote:
> * What to do about INCLUDING INDEXES EXCLUDING CONSTRAINTS --
> Postgres gets this wrong for unique indexes currently. Should we
> persist with the existing behaviour or fix it as part of this patch?
> My personal feeling was +1 for fixing it in this patch.

I'm not sure whether we came to a conclusion about this point.
The current code behavior is that INCLUDING INDEXES copies both
plain indexes and index-based constraints, while INCLUDING/EXCLUDING
CONSTRAINTS controls whether CHECK constraints are copied. Brendan
argues that this is wrong, and I agree that it's not what the syntax
would appear to mean. I think the most natural reading of the syntax
would be "INCLUDING INDEXES means to include everything you made
with CREATE INDEX syntax, while INCLUDING CONSTRAINTS means to
include everything you made with CONSTRAINT syntax". However, it's
unclear whether that's so much better or more useful as to justify
a compatibility break. Arguably, lumping all indexes together is
the most useful behavior in practice.

Another spanner in the works is that foreign-key constraints aren't
copied. Not to mention that simple NOT NULL constraints are always
copied independently of these options. So the whole thing fails to
satisfy the POLA by pretty much any standard.

Do we want to try to clean this up, or should we leave it alone on
backwards-compatibility grounds?

regards, tom lane