Wiebe Cazemier <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Because the rule converts those inserts into, effectively,
>>
>> INSERT INTO debuglog SELECT ... WHERE EXISTS(some matching OLD row);
>>
>> and there are no longer any matching OLD rows in the view.
> Is this behaviour also present
Tom Lane wrote:
So, the actual delete should be done after all the rules. And even if
it does delete before anything else, that does not explain why "step2"
is not inserted into the debuglog table.
Because the rule converts those inserts into, effectively,
INSERT INTO debuglog SELECT
Wiebe Cazemier <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm ... this appears to be a bug in EXPLAIN ANALYZE: it really should
>> bump the CommandCounter between plan trees, but fails to ...
> Is this something I have to report?
Nah, I fixed it already (only in CVS HEAD though).
Tom Lane wrote:
A quote from the postgresql manual:
"But for ON UPDATE and ON DELETE rules, the original query is done after the
actions added by rules. This ensures that the actions can see the to-be-updated
or to-be-deleted rows"
Yes, I know that quote. I wrote it. It's not relevant her
Wiebe Cazemier <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> The rule that actually deletes the rows from the underlying has to fire
>>> last, since the rows are gone from the view (and hence from OLD) the
>>> moment you delete them.
> A quote from the postgresql manual:
> "But for ON UPDATE
Tom Lane wrote:
> The rule that actually deletes the rows from the underlying has to fire
> last, since the rows are gone from the view (and hence from OLD) the
> moment you delete them.
A quote from the postgresql manual:
"But for ON UPDATE and ON DELETE rules, the original query is done after
Wiebe Cazemier <[EMAIL PROTECTED]> writes:
> which I manipulate with the view "rating_params". The delete rules on this
> view
> act very strangely.
The rule that actually deletes the rows from the underlying has to fire
last, since the rows are gone from the view (and hence from OLD) the
moment
Hi,
I've got the following table (contents not really relevant):
CREATE TABLE _rating_params (
id SERIAL PRIMARY KEY,
letter CHAR(1) NOT NULL CHECK (letter = 'E' OR letter = 'F'),
superparam_id INTEGER REFERENCES _rating_params,
seq_num INTEGER NOT NULL DEFAULT 1,
name_id INTEGER NOT N
