Re: merging some features from plpgsql2 project

2017-01-03 16:23 GMT+01:00 Merlin Moncure <mmoncure(at)gmail(dot)com>:

> On Tue, Dec 27, 2016 at 10:09 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
> wrote:
> > On 12/27/16 4:56 PM, Merlin Moncure wrote:
> >>
> >> On Tue, Dec 27, 2016 at 1:54 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
>