Re: bug: virtual generated column can be partition key
От | jian he |
---|---|
Тема | Re: bug: virtual generated column can be partition key |
Дата | |
Msg-id | CACJufxH63sfEPv=DGKoFZj1aUCBW-WfFvFHqp7ibGGepJxDvwA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: bug: virtual generated column can be partition key (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Ответы |
Re: bug: virtual generated column can be partition key
Re: bug: virtual generated column can be partition key |
Список | 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 по дате отправления: