From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Anna Akenteva <a(dot)akenteva(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ... |
Date: | 2020-09-08 14:50:44 |
Message-ID: | 61c1a22cce127e47f0bd80b4e9ab5cc445d975af.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-09-08 14:56:18 | Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ... |
Previous Message | Alvaro Herrera | 2020-09-08 14:49:19 | Re: Logical Replication - detail message with names of missing columns |