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

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 19:05:48
Message-ID: 1a0a5a4c-5ab0-3e84-9d1b-9e0ed650b729@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message hubert depesz lubaczewski 2022-03-17 14:24:26 Logical replication stops dropping used initial-sync replication slots
Previous Message Tom Lane 2022-03-16 17:27:56 Re: BUG #17439: DROP FUNCTION functionName(); drops associated generated column without using CASCADE