Dean Rasheed <dean.a.rash...@gmail.com> writes:
> Thanks for looking at this.
> Attached is a rebased patch using new OIDs.
I'm starting to look at this patch now. I don't understand the intended
interaction with qualified INSTEAD rules. The code looks like
+ if (!instead && rt_entry_relation->rd_rel->relkind ==
RELKIND_VIEW)
+ {
+ Query *query = qual_product ? qual_product : parsetree;
+ Query *newquery = rewriteTargetView(query,
rt_entry_relation);
which has the effect that if there's a qualified INSTEAD rule, we'll
apply the substitution transformation to the
modified-by-addition-of-negated-qual query (ie, qual_product).
This seems to me to be dangerous and unintuitive, not to mention
underdocumented. I think it would be better to just not do anything if
there is any INSTEAD rule, period. (I don't see any problem with DO
ALSO rules, though, since they don't affect the behavior of the original
query.)
Also, I didn't see anything in the thread concerning the behavior with
selective views. If we have say
CREATE VIEW v AS SELECT id, data FROM t WHERE id > 1000;
and we do
INSERT INTO v VALUES(1, 'foo');
the row will be inserted but will then be invisible through the view.
Is that okay? I can't find anything in the SQL standard that says it
isn't, but it seems pretty weird. A related example is
UPDATE v SET id = 0 WHERE id = 10000;
which has the effect of making the row disappear from the view, which is
not what you'd expect an UPDATE to do. Should we be doing something
about such cases, or is playing dumb correct?
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
