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.
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.
This would all be a little easier to accomplish if the behavior were
made to be implicit in the rewriter (ie, rewrite instead of throwing a
"no rule" error), since then there is no persistent state that a GUC or
reloption would have to try to add or get rid of. However, I do rather
like the idea that the auto rules are just a special case of some syntax
with wider usage than the auto rules themselves. So it's a tradeoff.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
