From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Alexander Lakhin <exclusion@gmail.com>,
        Amit Langote <amitlangote09@gmail.com>,
        pgsql-hackers@lists.postgresql.org,
        Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Subject: Re: ATTACH PARTITION seems to ignore column generation status
In-reply-to: <20230216180542.fdy5fnwkcbnhen6m@alvherre.pgsql>
References: <20230216180542.fdy5fnwkcbnhen6m@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Thu, 16 Feb 2023 19:05:42 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2334334.1676587222.1@sss.pgh.pa.us>
Date: Thu, 16 Feb 2023 17:40:22 -0500
Message-ID: <2334335.1676587222@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2334335.1676587222%40sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2023-Feb-16, Alexander Lakhin wrote:
>> I've encountered a query that triggers an assert added in that commit:
>> CREATE TABLE t(a int, b int GENERATED ALWAYS AS (a) STORED) PARTITION BY
>> RANGE (a);
>> CREATE TABLE tp PARTITION OF t(b DEFAULT 1) FOR VALUES FROM (0) to (1);

> It seems wrong that this command is accepted.  It should have given an
> error, because the partition is not allowed to override the generation
> of the value that is specified in the parent table.

Agreed.  We missed a check somewhere, will fix.

			regards, tom lane