Ya, I know I could pass them in. Just wanted to know if they were already floating around out there as globals or
something. That way I wouldn't have to drop/recreate the constraint itself.
These would be constraint violations where the name of the constraint being violated is in the returned message (should
therebe a violation). I named the constraints to identify the column and describe the nature of the problem. Not sure
howto capture that info if the trigger disallowed the value.
Also, I need to defer constraint checking for some transactions. Making the trigger sensitive to this deferral is not
somethingthat I wanted to devote a lot of time to. It just seemed more natural to keep this as a check constraint.
-----Original Message-----
From: Jerry Sievers [mailto:gsievers19@comcast.net]
Sent: Thursday, March 31, 2011 4:14 PM
To: Gauthier, Dave
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Access to NEW.column outside of a trigger function.
"Gauthier, Dave" <dave.gauthier@intel.com> writes:
> I have a check constraint that runs a PlPgsql function which returns a
> pass/ fail status which the constraint uses to allow or disallow the
> value. This is not a trigger function. It's just a plain-ole
> PlPgsql. Is there a way I can read (not write, just read) the
> NEW.column values that a trigger function would normally have access
> to?
Sure. Just pass them into your validator func as parameters.
But why are you avoiding use of a trigger here?
> Thanks in Advance for any help.
>
--
Jerry Sievers
Postgres DBA/Development Consulting
e: gsievers19@comcast.net
p: 305.321.1144
