If anyone is interested, here is my solution to my problem, which I hope
will be obsolete when the issues with the FDO PostGIS provider are
fixed. I have also successfully tested this setup out with foreign key
constraints in the primary table only --- the secondary tables just use
primary key cons
hello
2008/9/19 Michael Toews <[EMAIL PROTECTED]>:
> The INSERT and DELETE TG_OPs are straightforward (the simplest solution
> for these is that the existence of the primary key can be checked in the
> other table), however the UPDATE handler is really confusing.
>
> Is it possible for a trigger f
The INSERT and DELETE TG_OPs are straightforward (the simplest solution
for these is that the existence of the primary key can be checked in the
other table), however the UPDATE handler is really confusing.
Is it possible for a trigger function to know where an UPDATE originated
(user vs trigger)?
Hello
ad colum that will contains info about source of value
like
create table a(a integer, from_trigger bool);
create table b(a integer, from_trigger bool);
create or replace function synchronize_handler_a()
returns trigger as $$
begin
if not new.from_trigger then
new.from trigger := tru
