2017-01-03 16:23 GMT+01:00 Merlin Moncure <mmonc...@gmail.com>: > On Tue, Dec 27, 2016 at 10:09 PM, Jim Nasby <jim.na...@bluetreble.com> > wrote: > > On 12/27/16 4:56 PM, Merlin Moncure wrote: > >> > >> On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule <pavel.steh...@gmail.com > > > >> wrote: > >>> > >>> First I describe my initial position. I am strongly against > introduction > >>> "new" language - plpgsql2 or new plpgsql, or any else. The trust of > >>> developers to us is important and introduction of any not compatible or > >>> different feature has to have really big reason. PostgreSQL is > >>> conservative > >>> environment, and PLpgSQL should not be a exception. More - I have not > any > > > > > > Which is why this is an external fork of plpgsql. > > > > ** The real problem is that we have no mechanism for allowing a PL's > > language/syntax/API to move forward without massive backwards > compatibility > > problems. ** > > Just got back from break :-). Have some thoughts on this. Backwards > compatibility is really a fundamental problem. There's really no > solution to it other than to try and avoid using syntax to solve > problems. It should be obvious to everyone that plgsql cannot > withstand a compatibility break. Another language could be offered as > an alternative in core (say, pl/psm or pl/v8), but pl/pgsql has to > support old code. Some really out there features could maybe be > redacted (in particular, using = for assignment), but not not much. > But I guess we're stuck with the status quo. > > I think we ought to avoid language features that influence the > behavior (performance is ok) of the code (and that includes throwing > errors). That's a freight train headed towards javscript's 'strict' > mode, which is thinly disguised language fork. #option and pragma > type syntaxes are trying to cheat the language -- hardly anyone uses > them and it's a tricky way to try and make the language into something > other than it is. > > C does it right -- dubious code is raised as warnings and it's up to > the end user to determine which warnings are interesting and likely to > be an error. So, rather than hacking the language to control throwing > and errors and such there should be some ability validate the function > heavily and verify suspicious use of INTO or other dubious things > (unused variables, masked assignments, etc). The validation output > could even be a set returning function.
> 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) Do you know plpgsql_check https://github.com/okbob/plpgsql_check ? > > 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. > ??? > > *) Would also like to have a FINALLY block What you can do there? > > *) A mechanic to manually print out a stack trace for debugging > purposes would be helpful. > I had plan to develop a extension for this purpose - easy printing stack, function parameters, and local variables. But I had a motivation to start it. It can be usable for any PL > > *) COPY not being able to accept arguments as variables (in particular > the filename) is a major headache > There is a patch "COPY as function" > *) Upon error, we ought to print a few lines of context on either side > of the error. Not very fun to try and figure out where the errors is > when you are working off of 'syntax error near "FROM"' etc. This is a > major problem throughout the platform IMO. > Have not idea how to fix it > > *) 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. Regards Pavel > > merlin >
