2017-01-03 20:54 GMT+01:00 Merlin Moncure <mmonc...@gmail.com>: > On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > 2017-01-03 16:23 GMT+01:00 Merlin Moncure <mmonc...@gmail.com>: > >> So -1 to strict mode, unless we can make a case why this can't be done > >> as part of checking/validation. > > > > Can be plpgsq.extra_errors and plpgsql.extra_warnings solution? > > > > I am thinking so there is a space for improvement (in extra_* usage) > > extra_warnings seems ok at the GUC level. However it's bad to have a > body of code fail to compile based on GUC. check_function_bodies for > example is a complete hack and should be avoided if at all possible > IMO. There is very good informal rule that GUC should not impact > behavior (minus some special cases like timeouts). Good examples of > failure to follow this rule are mysql and php. > > Maybe settings at level of extension could be ok, but I'm skeptical. > Good languages are clear without needing extra context. > > > Do you know plpgsql_check https://github.com/okbob/plpgsql_check ? > > Yes. This is good design and should be model for core-work (if any). > In my ideal world, this could would be part of pgxn and to have pgxn > client be installed in core. For plpgsql to enter modern era we need > standardized packaging and deployment like cran, npm, etc. > > >> Other random points: > >> *) Another major pain point is swapping in the input variables for > >> debugging purposes. Something that emits a script based on a set of > >> arguments would be wonderful. > > > > ??? > > Often for debugging of complicated cases I'm starting from errors in > database log with function name and argument values. Sometimes I find > myself pasting pl/pgsql function into text editor and replacing input > variables with known values. >
is it related to plpgsql debugger? Have not idea how it can be better on language level. > > >> > >> *) Would also like to have a FINALLY block > > > > What you can do there? > > This is syntax sugar so you don't need second begin/end/exception > block or duplicated code. It separates error handling from cleanup. > > BEGIN > PERFORM dblink_connect(... > <risky_stuff> > EXCEPTION WHEN OTHERS THEN > <log/handle error> > FINALLY > PERFORM dblink_disconnect(... > END; > Does know somebody this pattern from Ada or PL/SQL? > > >> *) Some user visible mechanic other than forcing SQL through EXECUTE > >> to be able to control plan caching would be useful. > > > > fully agree. > > > > Have you some ideas? > > > > What about plpgsql option (function scope) -- WITHOUT-PLAN-CACHE - any > non > > trivial plans will not be cached - and evaluated as parametrized query > only. > > I have slight preference for syntax marker for each query, similar to > INTO. Maybe 'UNCACHED'? > I am not clean opinion - the statement level is nice, but what readability? SELECT UNCACHED t.a, t.b FROM INTO a,b; Regards Pavel > > On Tue, Jan 3, 2017 at 10:57 AM, Jim Nasby <jim.na...@bluetreble.com> > wrote: > > Or just fix the issue, provide the backwards compatability GUCs and move > on. > > I really don't think this will fly. I'm not buying your argument (at > all) that compatibility breaks have have been cleanly done in the > past, at least not in the modern era. In any event, marginal language > improvements are not a good justification to do it. And yes, the > continual monkey around with column names in pg_stat_activity are a > major hassle. For heaven's sake, can we just add new columns and/or > create a new view? > > merlin >
