On 2015-08-20 PM 10:19, David Fetter wrote: > On Thu, Aug 20, 2015 at 06:58:24PM +0900, Amit Langote wrote: >> >> Ah, I understand the point of parameterization (TRUST). Seems like it >> would be good to have with appropriate documentation of the same. Perhaps, >> it might as well a parameter to the step 1 itself. > > So TRUST would obviate step 2? Better still! >
I really wish we could do this in one step, but... As you know, primary intention behind keeping step 2 separate is to do the heavy validation work with access exclusive lock on the other table instead of on the master table. Assuming we add TRUST TO step 1 (with implications clarified in docs), when/if the user does not use TRUST, the default behavior being to perform the validation, would it be OK as it would have to take the expensive lock on the master table? Motivation for keeping the step 2 (and TRUST parameter with it) is really to avoid this last concern. All that said, we'd still need some way to tell rows that came from a TRUSTed table but do not really belong to the partition because we skipped checking that at all. Obviously one can always write a query on the partition that can find them, but some form of DDL would be what people might expect. >> >> Do you mean ATTACH and DETACH, if they require access exclusive lock on >> the parent, should not be in the first cut? Or am I misreading? > > Sorry I was unclear. > > ATTACH and DETACH should be in the first cut even if they require an > access exclusive lock. > Ah, got it. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers