Re: Rule updates and PQcmdstatus() issue

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Steve Howe <howe(at)carcass(dot)dhs(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Rule updates and PQcmdstatus() issue
Date: 2002-09-10 22:32:48
Message-ID: 200209102232.g8AMWm620829@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck wrote:
> Bruce Momjian wrote:
> >
> > Jan Wieck wrote:
> > > We should surely keep this on a much more technical level and avoid any
> > > personal offendings. To do so, please explain to me why you think that
> > > triggers and constraints are out of focus here? What is the difference
> > > between a trigger, a rule and an instead rule from a business process
> > > oriented point of view? I think there is none at all. They are just
> > > different techniques to do one and the same, implement business logic in
> > > the database system.
> >
> > All the problems here are coming from INSTEAD rules. We don't have
> > INSTEAD triggers or contraints.
>
> So a BEFORE INSERT trigger on table1 that does an UPDATE to table2 and
> then returns NULL is not effectively the same as an ON INSERT ... DO
> INSTEAD UPDATE ... rule? Hmmm, the end result is exactly the same so
> what do you call it?

Well, yes, functionally it is the same and we would have trouble dealing
with that too. I didn't know you could NULL return from a trigger and
it would exit the statement.

> I think we will have no chance to really return the number of
> VIEW-tuples affected. So any implementation is only a guess and we could
> simply return fixed 42 if "some" tuples where affected at all. This
> return is as wrong (according to Steve) as everything else but at least
> we have a clear definition what it means.

Yes, my guess is that accumulating everything with the same tags is the
closest we are going to get and does return the proper values in simple
multi-statement INSTEAD rules.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2002-09-10 23:05:03 Re: Optimization levels when compiling PostgreSQL...
Previous Message Oliver Elphick 2002-09-10 22:22:19 Re: