Re: ON COMMIT actions and inheritance - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: ON COMMIT actions and inheritance
Date
Msg-id 20181107005326.GB1677@paquier.xyz
Whole thread Raw
In response to Re: ON COMMIT actions and inheritance  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: ON COMMIT actions and inheritance
List pgsql-hackers
On Tue, Nov 06, 2018 at 07:04:17PM +0900, Amit Langote wrote:
> Agree with keeping it simple.  Maybe, we could (should?) document that the
> only ON COMMIT action that works when specified with partitioned parent
> table is DROP (other actions are essentially ignored)?

I have been thinking about this one, and here are some ideas:
- for ON COMMIT DROP:
When used on a partitioned table or a table with inheritance children,
this drops the depending partitions and children.
- for ON DELETE ROWS:
When used on a partitioned table, this is not cascaded to its
partitions.

> Seems fine to me.

Thanks for looking at the patch.

> +
> +    /*
> +     * Truncate relations before dropping so as all dependencies between
>
> so as -> so that

Fixed.

> +     * relations are removed after they are worked on.  This is a waste as it
> +     * could be possible that a relation truncated needs also to be removed
> +     * per dependency games but this makes the whole logic more robust and
> +     * there is no need to re-check that a relation exists afterwards.
> +     */
>
> "afterwords" seems redundant, but may I suggest rewriting the 2nd sentence as:
>
> Doing it like this might be a waste as it's possible that a relation being
> truncated will be dropped anyway due to it's parent being dropped, but
> this makes the code more robust because of not having to re-check that the
> relation exists.

Your comment sounds better, so added.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: shared-memory based stats collector
Next
From: "Imai, Yoshikazu"
Date:
Subject: RE: speeding up planning with partitions