From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, andrewbille(at)gmail(dot)com, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Dumping/restoring fails on inherited generated column |
Date: | 2020-09-29 20:01:09 |
Message-ID: | 6569EA45-268E-4635-B633-BEC5C2F73F4A@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 29 Sep 2020, at 18:37, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> [ Pulling Daniel into this older thread seems like the cleanest way to
> unify the two threads ]
>
> Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> writes:
>> If we have ALTER TABLE ONLY / DROP EXPRESSION update the attlocal
>> column of children to true to fix the issue you raised, my proposed
>> patch is not necessary. OTOH if we fix it by prohibiting the command,
>> I guess we need both patches to fix the issues.
>
> Right, Peter already mentioned that we need a further pg_dump fix on
> top of prohibiting the ONLY ... DROP EXPRESSION case.
>
> Bug #16622 [1] is another report of this same issue, and in that thread,
> Daniel argues that the right fix is just
>
> + /*
> + * Skip if the column isn't local to the table's definition as the attrdef
> + * will be printed with the inheritance parent table definition
> + */
> + if (!tbinfo->attislocal[adnum - 1])
> + return;
>
> without the attgenerated clause that Masahiko-san proposes.
> I think however that that's wrong. It is possible to have
> a non-attislocal column that has its own default, because
> you can do
Ah, that's the sequence I didn't think of. I agree with your assessment of
this being wrong. Thanks!
> This does not cause child2.f1's attislocal property to become
> true. Maybe it should have, but it's probably too late for
> that; at least, pg_dump couldn't assume it's true in older
> servers.
Do you recall the rationale for it not being set to true? I didn't spot
anything in the commit history. Intuitively it seems a tad odd.
> Therefore, since we can't tell whether the default
> is inherited or not, we'd better dump it.
Agreed.
> (I recall that pg_dump has a hack somewhere that checks for
> textual equality of CHECK conditions to avoid dumping redundant
> child copies. Maybe we could do something similar here.)
Unless someone beats me to it I will take a stab at this to see what it would
look like.
cheers ./daniel
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2020-09-29 20:16:14 | Re: BLOB / CLOB support in PostgreSQL |
Previous Message | Vladimir Sitnikov | 2020-09-29 19:48:42 | Re: BLOB / CLOB support in PostgreSQL |