Re: BUG #17439: DROP FUNCTION functionName(); drops associated generated column without using CASCADE
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: kmanh999@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2022-03-16T19:05:48Z
Lists: pgsql-bugs
On 15.03.22 21:06, Tom Lane wrote: > I looked into SQL:2021, and AFAICS the existing behavior is flat wrong, > even for cross references to other table columns. I think you read > 11.23 <drop column definition> general rule 3, which seems to say to > unconditionally drop any generated column depending on the target column > ... but you missed syntax rule 7f, which says > > 7) If RESTRICT is specified, then C shall not be referenced in any of the > following: > ... > f) The generation expression of any column descriptor. > > GR3 would be very strange if read in isolation anyway, because it > says to drop the generated column with CASCADE, which could cause > arbitrary stuff to go away. That is sensible if you know that 7f > prevents us from getting here unless the original drop said CASCADE, > but otherwise it's a pretty astonishing thing. The reported case is a DROP FUNCTION, but looking at <drop routine statement>, it doesn't say anything about what to do with generation expressions. That might be a bug in the standard, too.
Commits
-
Fix bogus dependency handling for GENERATED expressions.
- cb02fcb4c95b 15.0 landed
-
Move pg_attrdef manipulation code into new file catalog/pg_attrdef.c.
- 17f3bc09284e 15.0 landed