Re: bug: virtual generated column can be partition key - Mailing list pgsql-hackers

From jian he
Subject Re: bug: virtual generated column can be partition key
Date
Msg-id CACJufxH63sfEPv=DGKoFZj1aUCBW-WfFvFHqp7ibGGepJxDvwA@mail.gmail.com
Whole thread Raw
In response to Re: bug: virtual generated column can be partition key  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: bug: virtual generated column can be partition key
Re: bug: virtual generated column can be partition key
List pgsql-hackers
On Tue, Apr 22, 2025 at 11:45 AM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> I have included your original tests, but ended up rewriting code. Please let me know what do you think.
>

+ if (attno < 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
+ errmsg("partition key expressions cannot contain system column references")));
+
+ /*
+ * We do not check dropped columns explicitly since they will
+ * be eliminated when expanding the the whole row expression
+ * anyway.
+ */
typo: "the the".
I am confused by the above comments.
ComputePartitionAttrs only called in DefineRelation.
DefineRelation will only CREATE a table, there will be no dropped
column via DefineRelation.


+ /*
+ * transformPartitionSpec() should have already rejected
+ * subqueries, aggregates, window functions, and SRFs, based
+ * on the EXPR_KIND_ for partition expressions.
+ */
"EXPR_KIND_" can change to EXPR_KIND_PARTITION_EXPRESSION
?


Other than that, it looks good to me for fixing this bug.



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding
Next
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: Fix premature xmin advancement during fast forward decoding