Re: bug: virtual generated column can be partition key
jian he <jian.universality@gmail.com>
From: jian he <jian.universality@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-04-22T07:02:17Z
Lists: 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.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Tighten check for generated column in partition key expression
- 7f239c72a897 13.23 landed
- 04345d7a423a 14.20 landed
- 643a5e96c788 15.15 landed
- 7180d56c5609 16.11 landed
- 0b44f2443f69 17.7 landed
- ba99c9491c44 18.1 landed
- 040cc5f3c782 19 (unreleased) landed
-
Stamp 18beta1.
- caa76b91a606 18.0 cited