Re: BUG #17439: DROP FUNCTION functionName(); drops associated generated column without using CASCADE

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

In response to

Browse pgsql-bugs by date

  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