Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ... - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ...
Date
Msg-id 61c1a22cce127e47f0bd80b4e9ab5cc445d975af.camel@cybertec.at
Whole thread Raw
In response to Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ...  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ...  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Mon, 2020-09-07 at 11:42 -0300, Alvaro Herrera wrote:
> > This patch would provide a more convenient way to do that.
> > Again, I am not sure if that justifies the effort.
> 
> I have to admit I've seen cases where it'd be useful to have included
> columns in primary keys.
> 
> TBH I think if we really wanted the feature of primary keys with
> included columns, we'd have to add it to the PRIMARY KEY syntax rather
> than having an ad-hoc ALTER TABLE ALTER CONSTRAINT USING INDEX command
> to replace the index underneath.  Then things like pg_dump would work
> normally.
> 
> (I have an answer for the information_schema question Tom posed; I'd
> like to know what's yours.)

Gah, now I see my mistake.  I was under the impression that a
primary key can have an INCLUDE clause today, which is not true.

So this would introduce that feature in a weird way.
I agree that that is undesirable.

We should at least have

  ALTER TABLE ... ADD PRIMARY KEY (id) INCLUDE (val);

or something before we consider this patch.

As to the information_schema, that could pretend that the INCLUDE
columns just don't exist.

Yours,
Laurenz Albe




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Logical Replication - detail message with names of missing columns
Next
From: Alvaro Herrera
Date:
Subject: Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ...