Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] rules on INSERT can't UPDATE new instance?

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: ldm(at)apartia(dot)com, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, Jan Wieck <JanWieck(at)Yahoo(dot)com>
Subject: Re: [GENERAL] rules on INSERT can't UPDATE new instance?
Date: 2001-06-29 19:54:07
Message-ID: 200106291954.f5TJs7t14025@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
Jan, can you handle this TODO item?

	* Evaluate INSERT rules at end of query, rather than beginning


> 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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-06-29 20:25:56
Subject: Re: functions returning sets
Previous:From: Alex PilosovDate: 2001-06-29 18:46:40
Subject: functions returning sets

pgsql-general by date

Next:From: Micah YoderDate: 2001-06-29 21:26:08
Subject: Re: Re: useability of apache, PHP, Postgres for real business apps
Previous:From: mikeDate: 2001-06-29 19:31:39
Subject: multibyte tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group