Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors

2014-03-20 0:32 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Petr Jelinek <petr(at)2ndquadrant(dot)com> writes:
> > On 19/03/14 19:26, Alvaro Herrera wrote:
> >> I think this should have the GUC_LIST_INPUT flag, and ensure that when
> >> multiple values are passed, we can process them all in a sane fashion.
>
> > Well, as we said with Marko in the original thread, the proper handling
> > is left for whoever wants to add additional parameters, for the current
> > implementation proper list handling is not really needed and it will
> > only server to increase complexity of this simple patch quite late in
> > the release cycle.
>
> TBH, if I thought this specific warning was the only one that would ever
> be there, I'd probably be arguing to reject this patch altogether.
> Isn't the entire point to create a framework in which more tests will
> be added later?
>

I plan to work on plpgsql redesign this summer, so plpgsql check with same
functionality can be on next release, but should not be too.

This functionality doesn't change anything - and when we will have a better
tools, we can replace it without any cost, so I am for integration. It can
helps - plpgsql_check is next level, but it is next level complexity and
now it is not simply to integrate it. Proposed feature can server lot of
users and it is good API when we integrate some more sophisticated tool. I
like this interface - it is simple and good for almost all use cases that I
can to see.

Regards

Pavel

>
> Also, adding GUC_LIST_INPUT later is not really cool since it changes
> the parsing behavior for the GUC. If it's going to be a list, it should
> be one from day zero.
>
> regards, tom lane
>