2010/11/8 Merlin Moncure <mmonc...@gmail.com>: > On Mon, Nov 8, 2010 at 3:00 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: >>> Most cases of this feature are for dealing with new/old from trigger >>> function right? Why not build a complete new plan for each specific >>> trigger that invokes the function, along with some magic values like >>> (TG_FIELDNAMES -> text[]) that could be iterated for the mojo. Not >>> sure how you get direct type assignment to variable but it could >>> probably be worked out. >> >> if I understand well - it's not too far to my idea - just you create >> instance on function level? It is possible too. As disadvantages I >> see: >> a) you need some special syntax too >> b) there is overhead with multiple function call >> c) you have to manage some space for temporary values > > yes. If you need to deal with plan instance it should be at function > level IMO. There are other cases for this, search_path for example. > What overhead?
you call a trigger body more times then once. The call of plpgsql isn't cheep. Main problem is missing a some working memory. Task: ensure so sum of fields must be less than some constant? What is solution in your design? Pavel > > merlin > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
