Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors
Date
Msg-id 12903.1395271978@sss.pgh.pa.us
Whole thread Raw
In response to Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors  (Petr Jelinek <petr@2ndquadrant.com>)
Responses Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors  (Marko Tiikkaja <marko@joh.to>)
Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors  (Petr Jelinek <petr@2ndquadrant.com>)
List pgsql-hackers
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?

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.
Next
From: Andrew Dunstan
Date:
Subject: Re: jsonb status