Tom Lane wrote:
Bernd Helmle <maili...@oopsware.de> writes:
I originally had the idea of a GUC which controls wether automatic rules
will be generated or not. But I abonded this idea, since this has some kind
of "parametrized SQL standard functionality".
We have GUCs like that already, for exactly the same reason: backwards
compatibility with prior releases in which some feature didn't work as
per SQL standard. I think the argument that "no existing application
is going to be expecting these auto rules to appear" is pretty strong.
Arguably, pg_dump from an older version should make sure that the auto
rules should NOT get created, else it is failing to preserve an older
view's behavior.
+1
We certainly can't just throw old apps to the wolves in the name of
standards compliance.
The main question in my mind is whether we should have a turn-off
feature that is global (GUC) or per-view (reloption). One difficulty
with a reloption is that there's no way to set it on a view until after
you've done CREATE VIEW, whereupon it's too late --- the auto rules
are already there, and surely the reloption mechanism isn't going to
know how to make them go away.
Maybe something like CREATE VIEW .... WITHOUT UPDATE;
I actually like the idea of being able to turn update on and off for a view.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
