Re: Alter view with dependence without drop view!

On Tue, Jan 30, 2018 at 12:48 PM, David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Tue, Jan 30, 2018 at 8:34 AM, btober(at)computer(dot)org <
> btober(at)broadstripe(dot)net> wrote:
>
>>
>> When this procedure got old, I started using a script created using
>> pg_dump and pg_restore, as initially outlined here:
>>
>>
> ​Yeah, the short answer is PostgreSQL doesn't make it possible to edit
> "middle" views without having the code on hand for all dependent views​ so
> you can recreate them. You either maintain those views and order manually
> or you rely on pg_dump to figure it out for you (the former, with version
> control, is highly recommended).
>
> I could see it being possible to program the server to be more helpful
> here - by say allowing it to drop but remember view definitions and the
> re-create them from the remembered versions by name - but no one has seen
> the motivation to do so; I suspect partially in light of the fact that
> "version control" is a recommended practice.
>
> David J.
>
>

*Just a side note, it is not a good practice to create views based on other
views. *

*Multiple reasons are stated here:*

*https://dba.stackexchange.com/questions/5487/is-nested-view-a-good-database-design
<https://dba.stackexchange.com/questions/5487/is-nested-view-a-good-database-design>*

*To summarize, you suffer performance degradation, columns names and the
tables referenced become obscured and you incur the problems you are now
experiencing.*

--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.