2010/7/12 Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx>: > On 11/07/2010 5:46 AM, Pavel Stehule wrote: > >> any using a non simple expression is very slow - so there can be some >> a warning when people use it. Sometimes people don't know (me too), >> when use expensive expression >> >> for example >> >> rowvar := (10,20) >> >> it isn't simple - I am not sure, if it is true still. > > Rather than warning whenever the SPI is invoked from PL/PgSQL, perhaps this > would be a task better suited for inclusion in a profiler feature for the > PL/PgSQL debugger? > > I'm not particularly interested in the notion myself, but I don't think > warnings about "non-simple" statements would be very helpful. You'd be > drowned in warnings for statements that were a necessary part of the > operation of your functions, things for which there was no other way to do > it. I think, so it is warnings has more education sense. Because it is interactive. It simply show - "don't do it". More - it can be done in validation time - so it hasn't any impact on real speed (I know it is mas/menos). There are a few basic a plpgsql repeated mistakes - and I think so some of these can be catched via warnings. see http://okbob.blogspot.com/2010/04/frequent-mistakes-in-plpgsql-design.html I am thinking so plpgsql has a full functionality - there are not too much issues - so next direction of developing can be a smarted validation and more verbose diagnostics (now diagnostics (syntax error, runtime error) are pretty well). There a issue with assign statement with quite bin-text/text-bin transformation - declare a int; begin a := 4; because "4" is a numeric and "a" is integer, then in runtime time it does numeric/string and string to integer transformations. And it is relative innocent statement. Some like this are traps on beginners. > > It seems like a profiler, which is designed to filter and organize the > collected data, and which can be attached only to specific functions that > you want to know about, might be a better job. As there's already a PL/PgSQL > debugger, some of the infrastructure required is already present. there is a pl/pgsql profiler too. but profiler isn't "interactive". More - profiler/debugger are third-party software - so it isn't availlable everywhere. > > Meh, personally I'll stick to the good old profiling methods "is it fast > enough", "\timing", and "explain analyze". Both tools has a sense - we have a warnings in gcc and we have a profilers too. Regards Pavel Stehule > > -- > Craig Ringer > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general