On Mon, Nov 8, 2010 at 3:21 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 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?
nothing specific. My main interest is in the plan management portion (only because of side interest in search_path which is complete mess at present). if plpgsql_compile knows that it is trigger function and which table fired the trigger, you can generate specific hash key, and take advantage of new/old being well defined inside function execution. This seems less fiddly than trying to deal with plan mechanics inside the function. My knowledge stops there -- I don't have a real good understanding of how plpgsql works internally. If this idea passes smell test maybe it merits more research. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
