Re: [HACKERS] Re: Rules with Conditions: Bug, or Misunderstanding - Mailing list pgsql-sql

From Mark Hollomon
Subject Re: [HACKERS] Re: Rules with Conditions: Bug, or Misunderstanding
Date
Msg-id 00113022072200.00743@jupiter.hollomon.fam
Whole thread Raw
In response to Re: Rules with Conditions: Bug, or Misunderstanding  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Re: Rules with Conditions: Bug, or Misunderstanding  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-sql
On Wednesday 29 November 2000 19:42, Tom Lane wrote:
>
> Hm.  Perhaps the "cannot update view" test is too strict --- it's not
> bright enough to realize that the two rules together cover all cases,
> so it complains that you *might* be trying to update the view.  As the
> code stands, you must provide an unconditional DO INSTEAD rule to
> implement insertion or update of a view.

The idea was to check just before the update occurred to see if the 
destination was view. Maybe the test is too high up, before all rewriting
occurs.

It is in InitPlan, the same place we check to make sure that we are not 
changing a sequence or a toast table. (actually initResultRelInfo called from 
InitPlan). I gathered from the backend flowchart that this wasn't called 
until all rewriting was done. Was I wrong?

If all rewriting _is_ done at that point, why is the view still in the 
ResultRelInfo ?

-- 
Mark Hollomon


pgsql-sql by date:

Previous
From: Folke Ashberg
Date:
Subject: Re: [PHP] a script that queries database periodically
Next
From: Nelio Alves Pereira Filho
Date:
Subject: Help with Procedures in pgsql