From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hannu Krosing <hannu(at)tm(dot)ee> |
Cc: | Curt Sampson <cjs(at)cynic(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Rules and Views |
Date: | 2002-07-31 06:32:08 |
Message-ID: | 25598.1028097128@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)tm(dot)ee> writes:
> On Wed, 2002-07-31 at 10:22, Tom Lane wrote:
>> Hm. How about
>>
>> ERROR: Cannot insert into a view
>> You need an unconditional ON INSERT DO INSTEAD rule
> Seems more accurate, but actually you may also have two or more
> conditional rules that cover all possibilities if taken together.
> Maybe
> ERROR: Cannot insert into a view
> You need an ON INSERT DO INSTEAD rule that matches your INSERT
> Which covers both cases.
Actually not: the system insists that you provide an unconditional
DO INSTEAD rule. The other would require trying to prove (during
rule expansion) a theorem that the conditions of the available
conditional rules cover all possible cases.
Alternatively we could move the test for insertion-into-a-view out of
the rewriter and into a low level of the executor, producing an error
message only if some inserted tuple actually gets past the rule
conditions. I don't much care for that answer because (a) it turns a
once-per-query overhead check into once-per-tuple overhead, and
(b) if you fail to span the full space of possibilities in your rule
conditions, you might not find out about it until your application goes
belly-up in production. There's some version of Murphy's Law that says
rare conditions arise with very low probability during testing, and very
high probability as soon as you go live...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2002-07-31 06:41:41 | Re: WAL file location |
Previous Message | Curt Sampson | 2002-07-31 06:27:41 | Re: WAL file location |