Re: Generated column is not updated (Postgres 13)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Vitaly Ustinov <vitaly@ustinov.ca>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
pgsql-bugs@lists.postgresql.org,
"David G. Johnston" <david.g.johnston@gmail.com>
Date: 2021-05-20T15:53:12Z
Lists: pgsql-bugs
Attachments
- 0001-fix-tableoid-in-ATRewriteTable.patch (text/x-diff) patch 0001
- 0002-forbid-whole-row-in-generated.patch (text/x-diff) patch 0002
After looking at this further, I see that there already is a check for system columns in GENERATED expressions; it's just in the parser (scanNSItemForColumn), not where I was looking for it. And it explicitly exempts tableoid. I continue to think that that's a bad idea and we're gonna regret it, but at least the issue in ATRewriteTable turns out to be trivial to fix. So I did that and upgraded the test scenario to be a bit more realistic, in 0001 below. 0002 then just disallows whole-row variables. (I added an errdetail trying to explain that restriction, too.) It's worth pointing out here that what seems to me to be a "more realistic" test scenario involves a regclass constant for the table's own OID. If that doesn't scare you, it should, because it implies all kinds of constraints on the order in which these expressions are processed during CREATE or ALTER TABLE. The test passes check-world, which includes dump/reload, but I am sorely afraid that there are ways in which this sort of thing would fail. Do we *really* want to buy into supporting it? regards, tom lane
Commits
-
Disallow whole-row variables in GENERATED expressions.
- 61feb8670824 12.8 landed
- 849c7971d1ab 13.4 landed
- 4b10074453d1 14.0 landed
-
Fix usage of "tableoid" in GENERATED expressions.
- dfe51ffbe78a 12.8 landed
- 77e3204ecbf1 13.4 landed
- 2b0ee126bbf0 14.0 landed