Re: Default values, inserts, and rules...

> > ... That said, if things are working correctly in CVS, would you still
> > recommend a trigger over a rule?
>
> Yes I would. I don't think you've thought carefully enough about
> the implications of the statement that rules are macros... the
> perennial problem with macros is multiple evaluations of an
> argument, and if the argument has side-effects (like nextval()) you
> *will* get bit.

::nods:: I understand the HUGE pitfall of using NEXTVAL() or the like
in a rule: it makes complete sense. But given that the NEW tuple is
being correctly populated with both the sequence number default
values, I'd think a rule is an ideal way of copying the contents of
the insert + some logging/transaction goo into a logging table.

Let me phrase my question better: if the rule contains nothing more
than an insert statement into a duplicate logging table, is it faster
and more efficient to use a rule than a trigger? For pretty much
everything else I'm using triggers, but for logging purposes, rules
seem ideal. Triggers struck me as being heavier weight than rules in
terms of parsing and the context switch to execute some pl code in the
triger... err... hold the phone... wait a sec, I see what you were
getting at. This behavior seems broken. :~) Example:

CREATE TABLE t (pk SERIAL NOT NULL, c1 CHAR(1) NOT NULL, PRIMARY KEY(pk));
CREATE TABLE t_log (pk INT NOT NULL, c1 CHAR(1) NOT NULL);
CREATE RULE t_ins AS ON INSERT TO t DO INSERT INTO t_log (pk,c1) VALUES (NEW.pk,NEW.c1);
INSERT INTO t (c1) VALUES ('a');

SELECT * FROM t;
pk | c1
----+----
1 | a
(1 row)

SELECT * FROM t_log;
pk | c1
----+----
2 | a
(1 row)

What I get from this is that NEW.pk is doing a NEXTVAL() instead of
reading the value that the tuple was populated with from the sequence.
I can't think of an instance where this'd be the desired behavior...
kinda breaks the data consistency that I had expected.

The good news is though that the default values work like an absolute
CHARM and I can continue to use CURRVAL() in my rules... still, this
behavior seems a tad broken. There a good reason for this or could
you give me a filename to look into so I can toss together a patch.
Seems like something is going out of its way to get a new value from
the pk sequence when it shouldn't... thoughts? -sc

--
Sean Chittenden