Lists: | pgsql-general |
---|
From: | "Gauthier, Dave" <dave(dot)gauthier(at)intel(dot)com> |
---|---|
To: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Access to NEW.column outside of a trigger function. |
Date: | 2011-03-31 18:26:03 |
Message-ID: | 482E80323A35A54498B8B70FF2B87980048E0A51FF@azsmsx504.amr.corp.intel.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
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.
From: | Jerry Sievers <gsievers19(at)comcast(dot)net> |
---|---|
To: | "Gauthier\, Dave" <dave(dot)gauthier(at)intel(dot)com> |
Cc: | "pgsql-general\(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Access to NEW.column outside of a trigger function. |
Date: | 2011-03-31 20:14:24 |
Message-ID: | 871v1noxnj.fsf@comcast.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
"Gauthier, Dave" <dave(dot)gauthier(at)intel(dot)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(at)comcast(dot)net
p: 305.321.1144
From: | "Gauthier, Dave" <dave(dot)gauthier(at)intel(dot)com> |
---|---|
To: | Jerry Sievers <gsievers19(at)comcast(dot)net> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Access to NEW.column outside of a trigger function. |
Date: | 2011-03-31 20:22:56 |
Message-ID: | 482E80323A35A54498B8B70FF2B87980048E0A535C@azsmsx504.amr.corp.intel.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
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 there be a violation). I named the constraints to identify the column and describe the nature of the problem. Not sure 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 not something 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(at)comcast(dot)net]
Sent: Thursday, March 31, 2011 4:14 PM
To: Gauthier, Dave
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Access to NEW.column outside of a trigger function.
"Gauthier, Dave" <dave(dot)gauthier(at)intel(dot)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(at)comcast(dot)net
p: 305.321.1144
From: | Darren Duncan <darren(at)darrenduncan(dot)net> |
---|---|
To: | |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Access to NEW.column outside of a trigger function. |
Date: | 2011-03-31 22:03:45 |
Message-ID: | 4D94FA41.1060505@darrenduncan.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
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 (should there be a violation). I named the constraints to identify the column and describe the nature of the problem. Not sure 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 not something 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(at)comcast(dot)net]
> Sent: Thursday, March 31, 2011 4:14 PM
> To: Gauthier, Dave
> Cc: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] Access to NEW.column outside of a trigger function.
>
> "Gauthier, Dave" <dave(dot)gauthier(at)intel(dot)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.
>>
>