Re: Why cannot alter column type when a view depends on it? - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Why cannot alter column type when a view depends on it?
Date
Msg-id CAKFQuwbsMF41z81X_mZozaA01A-8oUcv9_DNJLeR+qLSBUK4Dg@mail.gmail.com
Whole thread Raw
In response to Why cannot alter column type when a view depends on it?  (Chao Li <li.evan.chao@gmail.com>)
Responses Re: Why cannot alter column type when a view depends on it?
List pgsql-hackers
On Sunday, September 28, 2025, Chao Li <li.evan.chao@gmail.com> wrote:

I tried to understand why this restriction is set, then I found that, when a function uses a view, the view can actually be dropped, only when the function is executed, it will raise an error saying the view doesn’t exist.

I’m doubting this applies to SQL-standard body functions where dependencies are actually tracked on the objects the function references.
 

In summary, this email is just raising the issue rather than proposing a solution. I want to hear feedbacks from the community. If people are interested in a solution to remove the restriction, then I can spend time on it.

I’d rather spend the effort providing something in pg_dump where you can give it a object_id and pg_dump will produce the DDL needed to recreate all of the views/etc in the correct order and the drop commands as well.  Making the alter table  “just work” seems just too problematic and limited to justify spending time on IMO.

David J.

pgsql-hackers by date:

Previous
From: Arseniy Mukhin
Date:
Subject: Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
Next
From: Xuneng Zhou
Date:
Subject: Re: Improve read_local_xlog_page_guts by replacing polling with latch-based waiting