On 26.04.21 14:10, Peter Eisentraut wrote:
On 05.02.21 15:18, Peter Eisentraut wrote:
Anyway, I figured out how to take account of generation expressions
with different column orders. I used the same approach that we use
for check constraints. The attached patch is good to go from my
perspec
On 05.02.21 15:18, Peter Eisentraut wrote:
Anyway, I figured out how to take account of generation expressions with
different column orders. I used the same approach that we use for check
constraints. The attached patch is good to go from my perspective.
Dusting this off ... this patch shoul
On 2021-02-04 01:17, Zhihong Yu wrote:
Hi,
+ if (attribute->attgenerated && !childatt->attgenerated)
+ ereport(ERROR,
...
+ if (attribute->attgenerated && childatt->attgenerated)
+ {
Looks like for the second if statement,
checking attribute->attgener
Hi,
+ if (attribute->attgenerated && !childatt->attgenerated)
+ ereport(ERROR,
...
+ if (attribute->attgenerated && childatt->attgenerated)
+ {
Looks like for the second if statement,
checking attribute->attgenerated should be enough (due to the check fr
On 2021-01-29 17:41, Tom Lane wrote:
Also, in the example from [2],
d3=# create table pp1 (a int, b int GENERATED ALWAYS AS (a * 2) STORED);
CREATE TABLE
d3=# create table cc1 (a int, b int GENERATED ALWAYS AS (a * 3) STORED);
CREATE TABLE
d3=# alter table cc1 inherit pp1;
ALTER TABLE
pg_dump n
Peter Eisentraut writes:
> On 2021-01-29 17:41, Tom Lane wrote:
>> However ... this doesn't solve all the cases noted in this thread.
>> In the first example I gave at [1],
>> d3=# create table parent (f1 int default 2);
>> CREATE TABLE
>> d3=# create table child (f1 int default 3) inherits(parent
On 2021-01-29 17:41, Tom Lane wrote:
However ... this doesn't solve all the cases noted in this thread.
In the first example I gave at [1],
d3=# create table parent (f1 int default 2);
CREATE TABLE
d3=# create table child (f1 int default 3) inherits(parent);
NOTICE: merging column "f1" with inh
On 2021-01-29 17:41, Tom Lane wrote:
Peter Eisentraut writes:
I've had another go at this, and I've found a solution that appears to
address all the issues I'm aware of. It's all very similar to the
previously discussed patches. The main difference is that previous
patches had attempted to us
Peter Eisentraut writes:
> I've had another go at this, and I've found a solution that appears to
> address all the issues I'm aware of. It's all very similar to the
> previously discussed patches. The main difference is that previous
> patches had attempted to use something like tbinfo->atti
I've had another go at this, and I've found a solution that appears to
address all the issues I'm aware of. It's all very similar to the
previously discussed patches. The main difference is that previous
patches had attempted to use something like tbinfo->attislocal to
determine whether a col
On 09.11.2020 13:43, Peter Eisentraut wrote:
On 2020-11-06 04:55, Masahiko Sawada wrote:
Both of these result in the same change to the dump output. Both of
them have essentially the same idea. The first one adds the
conditionals during the information gathering phase of pg_dump, the
second on
On 2020-11-06 04:55, Masahiko Sawada wrote:
Both of these result in the same change to the dump output. Both of
them have essentially the same idea. The first one adds the
conditionals during the information gathering phase of pg_dump, the
second one adds the conditionals during the output phas
On Wed, Nov 4, 2020 at 4:23 AM Peter Eisentraut
wrote:
>
> On 2020-08-27 13:30, Masahiko Sawada wrote:
> > This issue is not fixed yet. I've attached the updated version patch
> > and registered it to commit fest so as not to forget. Please review
> > it.
>
> A few fixes have been committed in thi
On 2020-08-27 13:30, Masahiko Sawada wrote:
This issue is not fixed yet. I've attached the updated version patch
and registered it to commit fest so as not to forget. Please review
it.
A few fixes have been committed in this thread, basically to prevent
situations that shouldn't have been allo
On 2020-09-25 15:07, Peter Eisentraut wrote:
We could probably fix this by having ALTER TABLE ONLY / DROP EXPRESSION
update the attlocal column of direct children to true, to make the
catalog state look like something that can be restored. However, that's
a fair amount of complicated code, so fo
On 2020-09-29 18:37, Tom Lane wrote:
Unfortunately this has still got a problem: it will mishandle the case of
a child column that is GENERATED while its parent is not. Peter opined
way upthread that we should not allow that, but according to my testing
we do.
Did I opine that? Commit 086ffdd
Daniel Gustafsson writes:
> On 29 Sep 2020, at 18:37, Tom Lane wrote:
>> 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 ra
> On 29 Sep 2020, at 18:37, Tom Lane wrote:
>
> [ Pulling Daniel into this older thread seems like the cleanest way to
> unify the two threads ]
>
> Masahiko Sawada writes:
>> If we have ALTER TABLE ONLY / DROP EXPRESSION update the attlocal
>> column of children to true to fix the issue you r
I wrote:
> The situation is different for GENERATED columns, since we disallow
> a child having a different GENERATED property than the parent.
BTW, that alleged prohibition is pretty damn leaky:
d3=# create table pp1 (a int, b int GENERATED ALWAYS AS (a * 2) STORED);
CREATE TABLE
d3=# create tab
[ Pulling Daniel into this older thread seems like the cleanest way to
unify the two threads ]
Masahiko Sawada 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 f
On Fri, 25 Sep 2020 at 22:07, Peter Eisentraut
wrote:
>
> I have been analyzing this issue again. We have a few candidate patches
> that do very similar things for avoiding dumping the generation
> expression of table gtest1_1. We can figure out later which one of
> these we like best. But ther
Peter Eisentraut writes:
> The proposed patches will cause the last statement to be omitted, but
> that still won't recreate the original state. The problem is that there
> is no command to make a column generated afterwards, like the SET
> DEFAULT command, so we can't dump it like this.
Righ
> On 25 Sep 2020, at 15:07, Peter Eisentraut
> wrote:
> We could probably fix this by having ALTER TABLE ONLY / DROP EXPRESSION
> update the attlocal column of direct children to true, to make the catalog
> state look like something that can be restored. However, that's a fair
> amount of co
I have been analyzing this issue again. We have a few candidate patches
that do very similar things for avoiding dumping the generation
expression of table gtest1_1. We can figure out later which one of
these we like best. But there is another issue lurking nearby. The
table hierarchy of gt
On Thu, 23 Jul 2020 at 19:55, Masahiko Sawada
wrote:
>
> On Thu, 16 Jul 2020 at 04:29, Tom Lane wrote:
> >
> > Peter Eisentraut writes:
> > >> Right, there were a number of combinations that were not properly
> > >> handled. The attached patch should fix them all. It's made against
> > >> PG12
On Thu, 16 Jul 2020 at 04:29, Tom Lane wrote:
>
> Peter Eisentraut writes:
> >> Right, there were a number of combinations that were not properly
> >> handled. The attached patch should fix them all. It's made against
> >> PG12 but also works on master. See contained commit message and
> >> do
Peter Eisentraut writes:
>> Right, there were a number of combinations that were not properly
>> handled. The attached patch should fix them all. It's made against
>> PG12 but also works on master. See contained commit message and
>> documentation for details.
> committed to master and PG12
S
On 2020-05-06 16:29, Peter Eisentraut wrote:
On 2020-04-23 08:35, Masahiko Sawada wrote:
After investigating this issue, I think that current DDLs regarding
inherited tables and generated columns seem not to work fine.
Right, there were a number of combinations that were not properly
handled.
On 2020-04-23 08:35, Masahiko Sawada wrote:
After investigating this issue, I think that current DDLs regarding
inherited tables and generated columns seem not to work fine.
Right, there were a number of combinations that were not properly
handled. The attached patch should fix them all. It'
I arrived at this thread while investigating the same issue recently
reported[1].
On Fri, 7 Feb 2020 at 04:36, Peter Eisentraut
wrote:
>
> On 2020-02-03 20:32, Tom Lane wrote:
> > Things are evidently also going wrong for "gtest1_1". In that case
> > the generated property is inherited from th
Peter Eisentraut writes:
> On 2020-02-03 20:32, Tom Lane wrote:
>> This is showing us at least two distinct problems. Now as for
>> "gtest30_1", what we have is that in the parent table "gtest30", column b
>> exists but it has no default; the generated property is only added
>> at the child table
On 2020-02-03 20:32, Tom Lane wrote:
> Things are evidently also going wrong for "gtest1_1". In that case
> the generated property is inherited from the parent gtest1, so we
> shouldn't be emitting anything ... how come the patch fails to
> make it do that?
This is fixed by the attached new patc
Peter Eisentraut writes:
> On 2019-12-04 21:36, Tom Lane wrote:
>> I wonder if the right fix is to not generate a DO_ATTRDEF
>> object at all for generated columns in child tables. Am
>> I right in guessing that we propagate generated-ness to
>> child tables automatically?
> Right. New patch us
On 2019-12-04 21:36, Tom Lane wrote:
I wonder if the right fix is to not generate a DO_ATTRDEF
object at all for generated columns in child tables. Am
I right in guessing that we propagate generated-ness to
child tables automatically?
Right. New patch using that approach attached. (Could use
Peter Eisentraut writes:
> On 2019-12-04 15:14, Tom Lane wrote:
>> It looks like gtest1_1 inherits column "b" from gtest1, so possibly
>> pg_dump is just confused about the combination of inheritance and
>> generated columns.
> Yeah, there was some stuff about the "separate" dumping of defaults t
On 2019-12-04 15:14, Tom Lane wrote:
Run the regression tests with "make installcheck", then:
$ pg_dump -Fc regression >r.dump
$ createdb r2
$ pg_restore -d r2 r.dump
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 6005; 2604 24821 DEFAULT gtest1_1 b postgres
pg_restore: error: coul
Run the regression tests with "make installcheck", then:
$ pg_dump -Fc regression >r.dump
$ createdb r2
$ pg_restore -d r2 r.dump
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 6005; 2604 24821 DEFAULT gtest1_1 b postgres
pg_restore: error: could not execute query: ERROR: column "b"
37 matches
Mail list logo
