Re: Proof of concept: auto updatable views [Review of Patch] - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Proof of concept: auto updatable views [Review of Patch]
Date
Msg-id CAEZATCXS-+q+c_r8JmyCHa8zdd9oO4oB2JiKMxT9=35SRJjoNQ@mail.gmail.com
Whole thread Raw
In response to Re: Proof of concept: auto updatable views [Review of Patch]  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proof of concept: auto updatable views [Review of Patch]
Re: Proof of concept: auto updatable views [Review of Patch]
List pgsql-hackers
On 7 November 2012 22:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dean Rasheed <dean.a.rasheed@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).

Yes that's what I was aiming for. I thought that if the rule's
qualifier isn't satisfied and the rule isn't fired, it should attempt
to go ahead with the view update. This might result in an INSTEAD OF
trigger firing, substitution of the base relation, or an error being
raised.

> 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.)
>

Is this any more dangerous than what already happens with qualified rules?

If we did nothing here then it would go on to either fire any INSTEAD
OF triggers or raise an error if there aren't any. The problem with
that is that it makes trigger-updatable views and auto-updatable views
inconsistent in their behaviour with qualified INSTEAD rules. I don't
think the existing interaction between trigger-updatable views and
qualified INSTEAD rules is documented, so perhaps that's something
that needs work.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Next
From: Josh Berkus
Date:
Subject: Re: auto_explain WAS: RFC: Timing Events