Thread: Access to NEW.column outside of a trigger function.

Access to NEW.column outside of a trigger function.

From
"Gauthier, Dave"
Date:

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?

 

Thanks in Advance for any help.

Re: Access to NEW.column outside of a trigger function.

From
Jerry Sievers
Date:
"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

Re: Access to NEW.column outside of a trigger function.

From
"Gauthier, Dave"
Date:
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

Re: Access to NEW.column outside of a trigger function.

From
Darren Duncan
Date:
From a design standpoint, CHECK constraints are better than triggers in
general, and if it is possible to do what you want in a CHECK constraint, you
should choose that option, and leave triggers for other tasks that you can't use
CHECK for.

Or to put this a different way, triggers are the proper way to do
non-deterministic things such as constraints or actions that depend on the
current system time, while CHECK is better for deterministic things such as
constraints a database should always have that only require looking at the
contents of the database itself.

-- Darren Duncan

Gauthier, Dave wrote:
> 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
(shouldthere be a violation).  I named the constraints to identify the column and describe the nature of the problem.
Notsure how to 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
notsomething that 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.
>>
>