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 по дате отправления: