Re: DO INSTEAD and conditional rules

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Wheeler <david(at)kineticode(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Neil Conway <neilc(at)samurai(dot)com>, Jan Wieck <JanWieck(at)yahoo(dot)com>
Subject: Re: DO INSTEAD and conditional rules
Date: 2005-04-26 18:20:16
Message-ID: 9287.1114539616@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Wheeler <david(at)kineticode(dot)com> writes:
> On Apr 26, 2005, at 8:55 AM, Tom Lane wrote:
>> Well, they handle simple situations OK, but we keep seeing people get
>> burnt as soon as they venture into interesting territory.

> [ snip ]

> Ah, yes, you're right, that is...unexpected. Perhaps OLD can contain
> its values for the duration of the RULE's statements? I'm assuming that
> what's happening is that OLD.id is NULL after the first of the two
> DELETE statements...

The problem is that OLD is effectively a macro for the view, and once
you've deleted one of the rows, that ID is no longer present anywhere in
the view. Sometimes you can work around this by making the join an
outer join, but that's certainly a kluge.

>> Like I said, I don't have a better idea. Just a vague feeling of
>> dissatisfaction.

> I'd call it a bug. ;-)

I don't think it's fixable without a fundamental rethinking of the
feature.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2005-04-26 18:52:56 pg_restore stuck in a loop?
Previous Message Oleg Bartunov 2005-04-26 16:35:24 Re: bitmapscan test, no success, bs is not faster