On 2006-04-11, Richard Huxton <dev@archonet.com> wrote: > Andrew - Supernews wrote: >> On 2006-04-11, Tom Lane <[EMAIL PROTECTED]> wrote: >>> I don't feel a need to offer specific examples as requested by Andrew. >> >> Why not? You're basing your entire argument on a false premise (that >> pl/pgsql is more powerful than SQL); I can provide specific examples of >> why this is not the case, or refute any that you care to provide. > > You can write trigger functions in plpgsql.
You can write rules without plpgsql. While rules and triggers are not equivalent, I think you'll be hard-pressed to come up with an example where a malicious intruder, with sufficient access to the system to create pl/pgsql functions if pl/pgsql is loaded, can carry out a useful attack using triggers that would not be possible without them. Let's try a simple example; changing the value of a column in future inserts into a table. Doing it without a trigger turns out to be simple; as a demonstration, this method allows an SQL function to be invoked: create function foox(foo) returns integer language sql as $$ update foo set value='bogus' where id=$1.id; select 1; $$; create rule foo_rule as on insert to foo do insert into bar values (foox(NEW)); insert into foo values (2,'bar'); INSERT 0 1 select * from foo; id | value ----+------- 1 | foo 2 | bogus (2 rows) So that's triggers without pl/pgsql. Anyone else want to try a challenge? -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
