| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | navbarry(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Postgres Partitions Limitations (5.11.2.3) |
| Date: | 2023-10-27 06:58:02 |
| Message-ID: | 40f7af960311be131d6d4bcb2caf7d93b79ddf5c.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-docs pgsql-hackers |
On Mon, 2023-01-09 at 16:40 +0100, Laurenz Albe wrote:
> > "Using ONLY to add or drop a constraint on only the partitioned table is
> > supported as long as there are no partitions. Once partitions exist, using
> > ONLY will result in an error. Instead, constraints on the partitions
> > themselves can be added and (if they are not present in the parent table)
> > dropped." This seems in contradiction to the example involving adding a
> > unique constraint while minimizing locking at the bottom of "5.11.2.2.
> > Partition Maintenance", which seems to run fine on my local Pg instance:
> >
> > This technique can be used with UNIQUE and PRIMARY KEY constraints too; the
> > indexes are created implicitly when the constraint is created. Example:
>
> No, that is actually an omission in the documentation.
>
> The attached patch tries to improve that.
I am sending a reply to the hackers list, so that I can add the patch to the commitfest.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2023-10-27 07:03:04 | Re: Version 14/15 documentation Section "Alter Default Privileges" |
| Previous Message | Laurenz Albe | 2023-10-27 06:48:49 | Re: unnest multirange, returned order |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Xiang Gao | 2023-10-27 07:01:10 | RE: CRC32C Parallel Computation Optimization on ARM |
| Previous Message | Michael Paquier | 2023-10-27 06:52:25 | Re: "38.10.10. Shared Memory and LWLocks" may require a clarification |