Message-ID: <40f7af960311be131d6d4bcb2caf7d93b79ddf5c.camel@cybertec.at>
Subject: Re: Postgres Partitions Limitations (5.11.2.3)
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: navbarry@gmail.com, pgsql-hackers@lists.postgresql.org
Date: Fri, 27 Oct 2023 08:58:02 +0200
In-Reply-To: <c8345f6323d6ea9c22e0f44125fd9815081c4c80.camel@cybertec.at>
References: <167299368731.659.16130012959616771853@wrigleys.postgresql.org>
	 <c8345f6323d6ea9c22e0f44125fd9815081c4c80.camel@cybertec.at>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/40f7af960311be131d6d4bcb2caf7d93b79ddf5c.camel%40cybertec.at>
Precedence: bulk

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 i=
s
> > supported as long as there are no partitions. Once partitions exist, us=
ing
> > ONLY will result in an error. Instead, constraints on the partitions
> > themselves can be added and (if they are not present in the parent tabl=
e)
> > 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=
:
> >=20
> > This technique can be used with UNIQUE and PRIMARY KEY constraints too;=
 the
> > indexes are created implicitly when the constraint is created. Example:
>=20
> No, that is actually an omission in the documentation.
>=20
> The attached patch tries to improve that.

I am sending a reply to the hackers list, so that I can add the patch to th=
e commitfest.

Yours,
Laurenz Albe