From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Amit kapila <amit(dot)kapila(at)huawei(dot)com>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proof of concept: auto updatable views [Review of Patch] |
Date: | 2012-11-07 22:44:32 |
Message-ID: | 20121107224432.GC18573@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 07, 2012 at 05:04:48PM -0500, Tom Lane wrote:
> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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?
The SQL standard handles deciding the behavior based on whether WITH
CHECK OPTION is included in the view DDL. See the section 2 of the
SQL standard (Foundation) for details.
Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2012-11-07 22:46:41 | Re: RFC: New log_destination 'fifo' |
Previous Message | Tom Lane | 2012-11-07 22:04:48 | Re: Proof of concept: auto updatable views [Review of Patch] |