From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | kmanh999(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17439: DROP FUNCTION functionName(); drops associated generated column without using CASCADE |
Date: | 2022-03-16 17:27:56 |
Message-ID: | 651168.1647451676@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
Attachment | Content-Type | Size |
---|---|---|
fix-generated-column-dependencies-1.patch | text/x-diff | 21.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-03-16 19:05:48 | Re: BUG #17439: DROP FUNCTION functionName(); drops associated generated column without using CASCADE |
Previous Message | Sergey Belyashov | 2022-03-16 12:09:30 | Re: BUG #17438: Logical replication hangs on master after huge DB load |