On 2021-Mar-21, Justin Pryzby wrote: > On Sun, Mar 21, 2021 at 03:22:00PM -0300, Alvaro Herrera wrote: > > > So if we do that on DETACH, what would happen on ATTACH? > > Do you mean what happens to the constraint that was already there ? > Nothing, since it's not ours to mess with. Checking ImpliedBy() rather than > equal() doesn't change that.
No, I meant what happens regarding checking existing values in the table: is the table scanned even if the partition constraint is implied by existing table constraints? > I proposed this a few years ago for DETACH (without concurrently), > specifically > to avoid the partition scans. > https://www.postgresql.org/message-id/20180601221428.gu5...@telsasoft.com > |The docs say: if detaching/re-attach a partition, should first ADD CHECK to > |avoid a slow ATTACH operation. Perhaps DETACHing a partition could > |implicitly CREATE a constraint which is usable when reATTACHing? Well, I agree with you that we should add such a constraint. -- Álvaro Herrera Valdivia, Chile "The problem with the future is that it keeps turning into the present" (Hobbes)
