Merlin Moncure wrote:
On Thu, Feb 4, 2010 at 7:36 PM, Tim Landscheidt wrote:
Any insight on a way I can grab NEW.(colRow.attname) without EXECUTE USING?
Wouldn't it be *much* easier to just have /two/ trigger
functions? Your "editor" columns probably don't pop up and
disappear random
On Thu, Feb 4, 2010 at 7:36 PM, Tim Landscheidt wrote:
>> Any insight on a way I can grab NEW.(colRow.attname) without EXECUTE USING?
>
> Wouldn't it be *much* easier to just have /two/ trigger
> functions? Your "editor" columns probably don't pop up and
> disappear randomly.
or, you could pass a
Mike Ginsburg wrote:
> [...]
> Thanks for the help! I'll look into the exceptions to see
> how expensive they are. On a related note, I was just told
> by our sysadmins that pg 8.4 might not be installed by the
> time this needs to be rolled out, leaving me in a bind since
> I have been using "
Merlin Moncure wrote:
On Thu, Feb 4, 2010 at 11:41 AM, Mike Ginsburg
wrote:
I have a plpgsql function that serves as a change log for a few tables in my
db (8.4.2). In most of the tables that I am logging, there is an "editor"
column that stores the ID of the user who made the change, so as
On Thu, Feb 4, 2010 at 11:41 AM, Mike Ginsburg
wrote:
> I have a plpgsql function that serves as a change log for a few tables in my
> db (8.4.2). In most of the tables that I am logging, there is an "editor"
> column that stores the ID of the user who made the change, so as part of the
> functio
I have a plpgsql function that serves as a change log for a few tables
in my db (8.4.2). In most of the tables that I am logging, there is an
"editor" column that stores the ID of the user who made the change, so
as part of the function I set
editor := NEW.editor;
There are a few of the tabl
