Re: contribute pg_get_viewdef2 et al

From: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, pgadmin-hackers(at)postgresql(dot)org
Subject: Re: contribute pg_get_viewdef2 et al
Date: 2003-05-07 13:56:56
Message-ID: 3EB910A8.7070807@web.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Hi Dave,

>I agree it looks pretty straightforward and simple. Try sending it to
>the hackers list though - I'll bet Tom gets loads of personally
>addressed queries and email everyday, and if he's like me gives
>preference to those that used the lists.
>
I did so, but had no response. Will try again soon.

>Yeah, but it doesn't work. Consider:
>
>CREATE TABLE foo (bar int4);
>CREATE VIEW foo_view AS
> SELECT
> bar
> FROM
> foo
> WHERE
> bar > 100;
>
><store view def>
>
>ALTER TABLE foo ALTER COLUMN bar RENAME TO sheep;
>
>At this point the stored view definition is no longer valid.
>
>
That's really a matter of philosophy. Taking MSSQL as an example, the
view wouldn't be runnable any more, if tables or columns are renamed. On
the other hand, tables can be dropped and recreated, and the view will
still be runnable because the saved plan is dropped and will be created
from source the first time it is used again.

As a solution in pgsql, there are two ways (combinable)
- Preventing table and column rename, if referenced by rules or views
(ALTER TABLE xx RENAME TO xx2 RESTRICT), just as DROP does
- invalidating the source, so only the reverse-engineered node
representation is available (ALTER TABLE xx RENAME TO xx2 CASCADE)

Regards,

Andreas

In response to

Browse pgadmin-hackers by date

  From Date Subject
Next Message Dave Page 2003-05-07 14:03:48 Re: contribute pg_get_viewdef2 et al
Previous Message Dave Page 2003-05-07 13:28:12 Re: contribute pg_get_viewdef2 et al