Re: Re: [SQL] Rules with Conditions: Bug, or Misunderstanding

From: Mark Hollomon <mhh(at)mindspring(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joel Burton" <jburton(at)scw(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-sql(at)postgresql(dot)org
Subject: Re: Re: [SQL] Rules with Conditions: Bug, or Misunderstanding
Date: 2000-12-01 03:07:22
Message-ID: 00113022072200.00743@jupiter.hollomon.fam
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 2000-12-01 04:00:12 Re: beta testing version
Previous Message Don Baccus 2000-12-01 01:57:44 Re: [HACKERS] Re: PHPBuilder article -- Postgres vs MySQL

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2000-12-01 04:46:18 Re: pltcl: missing close-brace
Previous Message Jonathan Ellis 2000-12-01 00:50:47 pltcl: missing close-brace