Re: Generated column is not updated (Postgres 13)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Vitaly Ustinov <vitaly(at)ustinov(dot)ca>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: Generated column is not updated (Postgres 13)
Date: 2021-05-20 01:18:29
Message-ID: 3568085.1621473509@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> FWIW I can definitely see where the OP is coming from with this - the
> expression at first blush, if one assumes PostgreSQL can handle the
> nuances, seems like a perfectly reasonable semantic way to express the
> programmer's desire. Combined with the fact it used to work makes me want
> to lean toward keeping it working even if it takes come code hackery.

I dunno, I think it "used to work" only for exceedingly small values
of "work". For me, the given test case hits the same assertion failure
in all versions back to v12, which is unsurprising because the code in
ATRewriteTable is about the same.

Also, considering only the table-rewrite code path is a mistake.
The fundamental problem here is that the behavior is ill-defined and
necessarily implementation-dependent; which makes it likely that other
code paths behave inconsistently with ALTER TABLE ADD COLUMN.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Mohan Nagandlla 2021-05-20 01:43:26 Re: BUG #17023: wal_log_hints not configured even if it on
Previous Message David Rowley 2021-05-20 01:06:31 Re: Less selective index chosen unexpectedly