From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@postgresql.org,
        Amit Langote <amitlangote09@gmail.com>
Subject: Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for
 inherited row triggers
In-reply-to: <20201020190420.GA18579@alvherre.pgsql>
References: <20201020190420.GA18579@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Tue, 20 Oct 2020 16:04:20 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <674283.1603223790.1@sss.pgh.pa.us>
Date: Tue, 20 Oct 2020 15:56:30 -0400
Message-ID: <674284.1603223790@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Hmm, next question: should we backpatch a fix for this?  (This applies
> all the way back to 11.)  If we do, then we would change behavior of
> partition creation.  It's hard to see that the current behavior is
> desirable ... and I think anybody who would have come across this, would
> wish it behaved the other way.  But still -- it would definitely be a
> behavior change.

The behavior change seems like it'd be an improvement in a vacuum,
but I wonder how it would interact with catalog contents left behind
by the old misbehavior.  Also, would we expect pg_dump to try to do
anything to clean up the mess?  If so, allowing a back branch to have
had more than one behavior would complicate that greatly.

			regards, tom lane