From: | Sean Chittenden <sean(at)chittenden(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Default values, inserts, and rules... |
Date: | 2002-08-21 17:07:10 |
Message-ID: | 20020821170710.GA46902@ninja1.internal |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-general |
> > There are two bits going on in this example:
> > 1) To get the current value from a sequence, I have to use
> > CURRVAL(seq_name) in the actual rule. Not that big of a deal, but
> > kind of a PITA that I can't just use NEW.s.
> > 2) When the rule does the insert into the t_log table, NEW.c1 doesn't
> > contain the default value of 42. How can I do this? I don't want
> > to force the application to specify the default values for
> > everything.
>
> This is a known bug in 7.2: default values that should be inserted
> into unspecified columns of an INSERT aren't inserted till after the
> rule rewriter, thus the rule text doesn't see 'em. This is fixed in
> CVS for 7.3, but I don't believe we have made a back-patch for 7.2
> branch. I believe this bug accounts for both your gripes.
Hrm, I think I'm just going to start developing against CVS then
because it also has the added perk of schemas which are perfect for
hiding log tables. ;~)
That said, if things are working correctly in CVS, would you still
recommend a trigger over a rule? I'd think that a macro/rule would be
faster than a trigger, but I don't have any real basis for my
statement. In my examples I'm using CURRVAL() and not NEXTVAL() so I
wouldn't worry about that being a problem.
-sc
--
Sean Chittenden
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-08-22 03:55:12 | Re: Default values, inserts, and rules... |
Previous Message | Jean-Luc Lachance | 2002-08-21 14:12:33 | Re: inconsistend performance |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2002-08-21 17:09:27 | Re: Limiting User Resources |
Previous Message | C F | 2002-08-21 16:45:31 | Limiting User Resources |