Hi Chris,
I beg to differ here. Say you have a set of business rules that
> I don't see
> any reason to create a record with a NULL and then replace that NULL
> before committing. Sort out program logic first; then look to the
> database.
rigidly defines how that field must be made AND the data on which it
is based is not visible to the user who does the insert. At this point
you need "something" to generate that value on the fly for the user
(calling a procedure from a before insert trigger).
You need that "something" either way, whether you supply it before the record is inserted or after. Stuff like that is best done as database logic, by means of a trigger or rule.
I have to admit that I don't know off the top of my head whether a NOT NULL constraint fires before ON INSERT triggers or after and I don't have access to PG from here to check that.
If that's the problem, then you might need to put a RULE in place instead of an ON BEFORE INSERT trigger. Is that what your complaint boils down to?
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.
