Re: pg_get_triggerdef in pg_dump

Поиск
Список
Период
Сортировка
От Andreas Pflug
Тема Re: pg_get_triggerdef in pg_dump
Дата
Msg-id 3EEF8BFE.8060602@web.de
обсуждение исходный текст
Ответ на Re: pg_get_triggerdef in pg_dump  (Rod Taylor <rbt@rbt.ca>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Extending PostgreSQL in C or C++
Следующее
От: Andreas Pflug
Дата:
Сообщение: Re: Extending PostgreSQL in C or C++