From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Marko Tiikkaja <marko(at)joh(dot)to> |
Subject: | Re: merging some features from plpgsql2 project |
Date: | 2017-01-03 15:58:25 |
Message-ID: | CAFj8pRBvabvGDchQ-JB4Ef+0L-y0AMc4r7azT9V3U01zYge+Sg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-01-03 15:59:11 | Re: Broken atomics code on PPC with FreeBSD 10.3 |
Previous Message | Tom Lane | 2017-01-03 15:54:55 | Re: [PATCH] Reload SSL certificates on SIGHUP |