Petr Jelinek <petr@2ndquadrant.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.