Re: merging some features from plpgsql2 project

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

> On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > 2017-01-03 16:23 GMT+01:00 Merlin Moncure <mmoncure(at)gmail(dot)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(dot)Nasby(at)bluetreble(dot)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
>