Re: Patch for 8.5, transformationHook
От | Pavel Stehule |
---|---|
Тема | Re: Patch for 8.5, transformationHook |
Дата | |
Msg-id | 162867790907260633x4941ef9el420c5e9ebdd68cf8@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Patch for 8.5, transformationHook (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
Hello note about SQL:201x http://blogs.mysql.com/peterg/2009/06/07/soothsaying-sql-standardization-stuff/ regards Pavel Stehule 2009/7/26 Pavel Stehule <pavel.stehule@gmail.com>: > Hello > > new patch add new contrib "transformations" with three modules > anotation, decode and json. > > These modules are ported from my older work. > > Before applying this patch, please use named-fixed patch too. The hook > doesn't need it, but modules anotation and json depend on it. > > Regards > Pavel Stehule > > 2009/7/26 Robert Haas <robertmhaas@gmail.com>: >> On Sat, Jul 25, 2009 at 11:38 PM, Pavel Stehule<pavel.stehule@gmail.com> wrote: >>> Hello >>> >>> 2009/7/25 Robert Haas <robertmhaas@gmail.com>: >>>> On Mon, Apr 20, 2009 at 8:45 AM, Pavel Stehule<pavel.stehule@gmail.com> wrote: >>>>> 2009/4/18 Tom Lane <tgl@sss.pgh.pa.us>: >>>>>> Pavel Stehule <pavel.stehule@gmail.com> writes: >>>>>>> 2009/4/11 Tom Lane <tgl@sss.pgh.pa.us>: >>>>>>>> No, I was complaining that a hook right there is useless and expensive. >>>>>>>> transformExpr() is executed multiple times per query, potentially a very >>>>>>>> large number of times per query; so even testing to see if a hook exists >>>>>>>> is not a negligible cost. >>>>>> >>>>>>> I did some tests based on pgbench. >>>>>> >>>>>> The queries done by pgbench are completely trivial and do not stress >>>>>> parser performance. Even if they did (consider cases likw an IN with a >>>>>> few thousand list items), the parser is normally not a bottleneck >>>>>> compared to transaction overhead, network round trips, and pgbench >>>>>> itself. >>>>>> >>>>>>> I though about different position of hook, but only in this place the >>>>>>> hook is useful (because expressions are recursive). >>>>>> >>>>>> As I keep saying, a hook there is useless, at least by itself. You >>>>>> have no control over the grammar and no ability to modify what the >>>>>> rest of the system understands. The only application I can think of is >>>>>> to fool with the transformation of FuncCall nodes, which you could do in >>>>>> a much lower-overhead way by hooking into transformFuncCall. Even that >>>>>> seems pretty darn marginal for real-world problems. >>>>>> >>>>> >>>>> I am sending modified patch - it hooking parser via transformFuncCall >>>> >>>> I am reviewing this patch. It seems to me upon rereading the thread >>>> that the objections Tom and Peter had to inserting a hook into >>>> transformExpr() mostly still apply to a hook in transformFuncCall(): >>>> namely, that there's no proof that putting a hook here is actually >>>> useful. I think we should apply the same criteria to this that we >>>> have to some other patches that have been rejected (like the >>>> extensible-rmgr patch Simon submitted for CommitFest 2008-11), namely, >>>> requiring that the extension mechanism be submitted together with at >>>> least two examples of how it can be used to interesting and useful >>>> things, bundled as one or more contrib modules. >>> >>> I have in my plan add to contrib JSON support similar to Bauman design: >>> >>> http://www.mysqludf.org/lib_mysqludf_json/index.php >>> >>> It's will be sample of "smart" functions. Because this need more then >>> less work I am waiting on commit. >>> >>> Other simple intrduction contrib module should be real Oracle decode >>> function - I sent source code some time ago. But this code needs some >>> modification. I should send this code if you need it. >> >> Sure, post it and let's discuss. >> >> ...Robert >> >
В списке pgsql-hackers по дате отправления: