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
