Re: ATTACH PARTITION seems to ignore column generation status

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: ATTACH PARTITION seems to ignore column generation status
Date: 2023-01-12 03:00:22
Message-ID: CA+HiwqG2v-SnWyJuyVM-Z8DEFukY8+qe3XLMwSG4Xp7Yf=RioA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 12, 2023 at 5:58 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> > I've updated your disallow-generated-child-columns-2.patch to do this,
> > and have also merged the delta post that I had attached with my last
> > email, whose contents you sound to agree with.
>
> Pushed with some further work to improve the handling of multiple-
> inheritance cases. We still need to insist that all or none of the
> parent columns are generated, but we don't have to require their
> generation expressions to be alike: that can be resolved by letting
> the child table override the expression, much as we've long done for
> plain default expressions. (This did need some work in pg_dump
> after all.) I'm pretty happy with where this turned out.

Thanks, that all looks more consistent now indeed.

I noticed a typo in the doc additions, which I've attached a fix for.

--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com

Attachment Content-Type Size
8bf6ec3ba3-doc-typo.patch application/octet-stream 732 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2023-01-12 03:03:38 Re: Time delayed LR (WAS Re: logical replication restrictions)
Previous Message Ted Yu 2023-01-12 02:55:18 Re: releasing ParallelApplyTxnHash when pa_launch_parallel_worker returns NULL