Re: BUG #17439: DROP FUNCTION functionName(); drops associated generated column without using CASCADE
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: kmanh999@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2022-03-16T17:27:56Z
Lists: pgsql-bugs
Attachments
- fix-generated-column-dependencies-1.patch (text/x-diff) patch
I wrote: > Ugh ... this opens a much larger can of worms than I thought. After some fooling around, here's a draft patch for this. I needed functions to convert between pg_attrdef OIDs and owning column's table OID + attnum. There was already some ad-hoc code for that in objectaddress.c, which I extracted into standalone functions. It seemed cleaner to put those into heap.c (beside StoreAttrDefault) than keep them in objectaddress.c; but perhaps someone else will see that differently. I'm about half tempted to shove StoreAttrDefault, RemoveAttrDefault, and these new functions into a new file catalog/pg_attrdef.c, just to make heap.c a bit smaller. But I didn't undertake that here. Otherwise it seems mostly straightforward, but I remain concerned that I've missed place(s) that depend on the previous arrangement. regards, tom lane
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