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. 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 *) A mechanic to manually print out a stack trace for debugging purposes would be helpful. *) COPY not being able to accept arguments as variables (in particular the filename) is a major headache *) 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. *) Some user visible mechanic other than forcing SQL through EXECUTE to be able to control plan caching would be useful. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
