From: | Stef <stef(at)ummon(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Obtaining Firing Statement clause in (pl/perlu) Trigger Function |
Date: | 2005-05-23 16:16:03 |
Message-ID: | 20050523161602.GC4766@survivor.hades |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Everyone,
Apologies in advance, its time for another of my whacky 'can we do
this' emails ;)
I am trying to write a function/Trigger in pl/perl (although any
other language which allows this is perfectly fine with me :) and I need to
find the firing statement. I understand that if the trigger was fired in
a long sequence, then of course, the calling statement will be the
previous trigger.
The scenario comes from that I am trying to setup a function which
queries a remote Sybase server. I have the functionality such that this
works;
select * from test_func('where userid=2313423');
It then returns a SETOF the table in question. However, the syntax
is, to put it politely, klunky (it smells of a kludge, which, it is :).
Therefore, if I can get access to the where section of the calling
statement in the Trigger itself, i can have a syntax which reads as
follows;
select * from test_func() where userid=2324142;
The reason for needing the syntax inside the Trigger, is obviously
with large tables, grabbing all the tuples and then parsing them down
once obtained is, rather crazy. Some of the tables in question have at
least 3 million records. Flinging them all around only to get a few (or
most of the time one) seems rather crazy.
Do any of the pl/XXXX languages support getting at the calling
trigger statement ?
I am not adverse to trying to 'fix' pl/perl, however, if the trigger
never even gets passed this information in the first place, well, things are
going to start getting messy, and probably spiral outside of my control
:)
Regards and Thanks
Stef
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2005-05-23 16:20:16 | Re: PATCH to allow concurrent VACUUMs to not lock each |
Previous Message | Stephen Frost | 2005-05-23 16:08:21 | Re: inet increment w/ int8 |