Re: pg_get_triggerdef in pg_dump - Mailing list pgsql-hackers

From Andreas Pflug
Subject Re: pg_get_triggerdef in pg_dump
Date
Msg-id 3EEF8BFE.8060602@web.de
Whole thread Raw
In response to Re: pg_get_triggerdef in pg_dump  (Rod Taylor <rbt@rbt.ca>)
List pgsql-hackers
Rod Taylor wrote:

>>What I *really* want is having the original source stored, including 
>>comments, version info, ... Currently, it's argued that underlying table 
>>and column might change, braking the view/rule. This could be 
>>restricted, or source could be dropped (alter table ... cascaded). Is it 
>>really only me who  tries to put complicated views into pgsql and wants 
>>to understand them 10 days later? We do have an enterprise grade RDBMS, 
>>don't we?
>>    
>>
>
>You could argue that comments should be converted to an 'information'
>node within the query structure which contains comments.  They would
>then be dumped back out to the user.
>
>But I think you would be dissapointed if you were returned the view that
>is no longer correct since someone renamed the tables.
>
>  
>
Rod,
this arguments are quite academic. On one side, this could be 
restricted, thats what pg_depends is good for (this already happens for 
inherited tables).
On the other side, how often do you rename columns or tables?
On mssql, nobody cares. If you fool around with names, your views will 
be broken without warning. pgsql could be better easily.
I'd really prefer to have full view sources available rather than the 
gimmick of stable views despite renamed cols/tabs.

Regards,
Andreas



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Extending PostgreSQL in C or C++
Next
From: Andreas Pflug
Date:
Subject: Re: Extending PostgreSQL in C or C++