Re: Trigger functions with dynamic SQL - Mailing list pgsql-sql

From Andreas Haumer
Subject Re: Trigger functions with dynamic SQL
Date
Msg-id 41051D50.5060409@xss.co.at
Whole thread Raw
In response to Re: Trigger functions with dynamic SQL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-sql
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I have solved the problem!

Tom Lane wrote:
> Andreas Haumer <andreas@xss.co.at> writes:
>
>>I just can't figure out where and how many quotation marks
>>I have to place in my function.
>
>
> It's messy all right.  The "dollar quoting" feature in 7.5 should make
> it a lot less painful, since you can stop having to double and re-double
> quote marks.  If you're interested in using beta-quality code, you can
> have that today.  An example would go something like
>
> CREATE FUNCTION mytrigger() RETURNS trigger AS $PROC$
>   DECLARE
>   ...
>   EXECUTE $$ SELECT ... FROM $$ || tgargv[0] || $$ WHERE col = 'key' $$;
>   ...
>   END
> $PROC$ LANGUAGE plpgsql;
>
> Here I've used minimal dollar quotes ($$) for the literal constant parts
> of the EXECUTE'd query, which allows me not to have to double the quote
> marks that I actually want in the query text (the ones around "key").
> And I used dollar quotes with a label ($PROC$) at the outermost level
> to quote the entire function body, so that there's no conflict with the

Yes, this "dollar quoting" seems to make things a lot clearer!

> embedded dollar quotes.  In 7.4 the same EXECUTE command would have to
> be written
>
>   EXECUTE '' SELECT ... FROM '' || tgargv[0] || '' WHERE col = ''''key'''' '';
>
> which is already getting painful, and more complex cases get rapidly
> worse.  With dollar quoting you can write the constant parts of your
> query the same way you normally would.
>
As I currently use 7.4 I had to stick with lots of quotation marks,
but I finally managed to get it right and it works!

My plpgsql generic trigger function for maintaining referential
integrity with temporal tables now looks as follows:

CREATE FUNCTION func_fk_temporal_trigger () RETURNS "trigger"   AS '
DECLARE referer_tab text; referer_col text; referenced_tab text; referenced_col text; stmt varchar(4000); result
record;

BEGIN referer_tab := TG_ARGV[0]; referer_col := TG_ARGV[1]; referenced_tab := TG_ARGV[2]; referenced_col :=
TG_ARGV[3];
 stmt := '' SELECT id FROM '' || quote_ident(referer_tab); stmt := stmt || '' WHERE '' || quote_ident(referer_tab) ||
''.bis= ''''infinity'''' ''; stmt := stmt || '' AND '' || quote_ident(referer_tab) || ''.'' || quote_ident(referer_col)
||'' IS NOT NULL''; stmt := stmt || '' AND NOT EXISTS (SELECT id FROM '' || quote_ident(referenced_tab); stmt := stmt
||'' WHERE '' || quote_ident(referer_tab) || ''.'' || quote_ident(referer_col) || '' = '' ||
quote_ident(referenced_tab)|| ''.'' || quote_ident(referenced_col); stmt := stmt || '' AND '' ||
quote_ident(referenced_tab)|| ''.bis = ''''infinity'''')'';
 
 FOR result IN EXECUTE stmt LOOP   RAISE EXCEPTION ''temporal table referential integrity violation - key referenced
from%.% not found in %.%'', referer_tab, referer_col, referenced_tab, referenced_col; END LOOP;
 
 RETURN new;
END;
'   LANGUAGE plpgsql;

And these are some of the trigger definitions which use this function:

CREATE TRIGGER trigger_fk_pns_ug   AFTER INSERT OR UPDATE ON t_pns   FOR EACH ROW   EXECUTE PROCEDURE
func_fk_temporal_trigger('t_pns', 'ug', 't_ug', 'id');
 


CREATE TRIGGER trigger_fk_ug_pns   AFTER DELETE OR UPDATE ON t_ug   FOR EACH ROW   EXECUTE PROCEDURE
func_fk_temporal_trigger('t_pns', 'ug', 't_ug', 'id');
 


CREATE TRIGGER trigger_fk_pnspar_pns   AFTER INSERT OR UPDATE ON t_pnspar   FOR EACH ROW   EXECUTE PROCEDURE
func_fk_temporal_trigger('t_pnspar', 'pns', 't_pns', 'id');
 


CREATE TRIGGER trigger_fk_pnspar_par   AFTER DELETE OR UPDATE ON t_pnspar   FOR EACH ROW   EXECUTE PROCEDURE
func_fk_temporal_trigger('t_pnspar', 'par', 't_par', 'id');
 

[...]

With this single generic trigger function I can now save myself
of writing (and maintaining) literally dozends of specialized
functions. From what I can say after a few tests it seems to
work quite fine!

Note that I use "FOR result IN EXECUTE stmt LOOP" to process the
results of the dynamic query. To avoid this, I first tried to put
the whole function body including the "RAISE EXCEPTION" statement
into the dynamic query, but it seems the plsql parser doesn't like
this.

May I suggest to put this or a similar example into the
PostgreSQL manual in chapter 35 (Triggers) and/or 37.6.4
(Executing Dynamic Commands)? I'm sure this will save
other peoples time (ok, one can also use google to find
this mail in the archives... ;-)

Regards,

- - andreas

- --
Andreas Haumer                     | mailto:andreas@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBBR1OxJmyeGcXPhERAo20AKDDv5pOi/3PMx1RhbKzQqIMv9rdOwCgvQIS
XAzqpB+j1i92ao0FHOkh/kY=
=0xfX
-----END PGP SIGNATURE-----



pgsql-sql by date:

Previous
From: sad
Date:
Subject: Re: surrogate key or not?
Next
From: Karsten Hilbert
Date:
Subject: Re: surrogate key or not?