| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| 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:56:18 |
| Message-ID: | 20200908145618.GA14279@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2020-Sep-08, Laurenz Albe wrote:
> We should at least have
>
> ALTER TABLE ... ADD PRIMARY KEY (id) INCLUDE (val);
>
> or something before we consider this patch.
Agreed.
Now the trick in this new command is to let the user change the included
columns afterwards, which remains useful (since it's clearly reasonable
to change minds after applications using the constraint start to take
shape).
> As to the information_schema, that could pretend that the INCLUDE
> columns just don't exist.
Yeah, that's what I was thinking too, since for all intents and
purposes, from the standard's POV the constraint works the same
regardless of included columns.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2020-09-08 15:21:00 | Re: proposal - reference to plpgsql_check from plpgsql doc |
| Previous Message | Laurenz Albe | 2020-09-08 14:50:44 | Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ... |