From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [GENERAL] rules on INSERT can't UPDATE new instance? |
Date: | 2001-01-24 13:45:44 |
Message-ID: | 200101241345.IAA12218@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Comments on this? Seems INSERT should happen at the end. Is this a
trivial change?
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Is the INSERT rule re-ordering mentioned a TODO item?
>
> Darn if I know. I threw the thought out for discussion, but didn't
> see any comments. I'm not in a hurry to change it, unless there's
> consensus that we should.
>
> regards, tom lane
>
>
> >> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> >>>> I thought an INSERT rule with an UPDATE action would work on the same
> >>>> table, but that fails. Seems the rule is firing before the INSERT
> >>>> happens.
> >>
> >> Yes, a trigger is the right way to do surgery on a tuple before it is
> >> stored. Rules are good for generating additional SQL queries that will
> >> insert/update/delete other tuples (usually, but not necessarily, in
> >> other tables). Even if it worked, a rule would be a horribly
> >> inefficient way to handle modification of the about-to-be-inserted
> >> tuple, because (being an independent query) it'd have to scan the table
> >> to find the tuple you are talking about!
> >>
> >> The reason the additional queries are done before the original command
> >> is explained thus in the source code:
> >>
> >> * The original query is appended last if not instead
> >> * because update and delete rule actions might not do
> >> * anything if they are invoked after the update or
> >> * delete is performed. The command counter increment
> >> * between the query execution makes the deleted (and
> >> * maybe the updated) tuples disappear so the scans
> >> * for them in the rule actions cannot find them.
> >>
> >> This seems to make sense for UPDATE/DELETE, but I wonder whether
> >> the ordering should be different for the INSERT case: perhaps it
> >> should be original-query-first in that case.
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Rieke | 2001-01-24 13:57:10 | Performance problem |
Previous Message | Bruce Momjian | 2001-01-24 13:44:16 | Re: [GENERAL] child table doesn't inherit PRIMARY KEY? |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-01-24 13:47:20 | Re: Minor buglet in update...from (I think) |
Previous Message | Bruce Momjian | 2001-01-24 13:44:16 | Re: [GENERAL] child table doesn't inherit PRIMARY KEY? |