From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tarlika Elisabeth Schmitz <postgresql3(at)numerixtechnology(dot)de> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: trigger - dynamic WHERE clause |
Date: | 2011-05-31 04:09:18 |
Message-ID: | BANLkTim5R_FVHvm9EEZ9NcRMqgCzXsD3wg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2011/5/31 Tarlika Elisabeth Schmitz <postgresql3(at)numerixtechnology(dot)de>:
> On Mon, 30 May 2011 11:02:34 +0200
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
>>> 2) I took from your blog entry
>>> (http://okbob.blogspot.com/2008/06/execute-using-feature-in-postgresql-84.html)
>>> that it is good practice to use EXECUTE USING.
>>> Well, there's no danger of SQL injection as this particular DB runs
>>> on an internal network. However, I am wondering whether EXECUTE
>>> USING has a performance advantage?
>>>
>>
>>You newer know where or who is attacker :)
>>The performance is very similar now - the most slow part is generating
>>of execution plan - not IO operations.
>
> I have converted my generic trigger to use EXECUTE ... USING.
>
> I need to convert all NEW values to a text array, retaining their
> ordinal position.
> avals(hstore(NEW)) doesn't seem to do that:
>
> NEW: (5,name5,1000,,,2)
> avals(hstore(NEW)): {5,name5,2,1000,NULL,NULL}
>
> The best I can come up with is a JOIN with information_schema.columns.
jup
it should be relative expensive (slow). If you need a generic triggers
use different PL instead. I can not to know what requests you have to
solve. But try to look on PLPerl or PLPython. Generic triggers can be
developed there with less work.
Regards
Pavel
>
> --
>
> Best Regards,
> Tarlika Elisabeth Schmitz
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2011-05-31 06:22:38 | Re: Index Size |
Previous Message | Nick Raj | 2011-05-31 03:33:39 | Re: Index Size |