Re: pg_get_triggerdef in pg_dump

From: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>
To: Rod Taylor <rbt(at)rbt(dot)ca>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_get_triggerdef in pg_dump
Date: 2003-06-17 21:45:34
Message-ID: 3EEF8BFE.8060602@web.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Pflug 2003-06-17 21:51:34 Re: Extending PostgreSQL in C or C++
Previous Message Tom Lane 2003-06-17 21:42:23 Re: Extending PostgreSQL in C or C++