| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Marko Tiikkaja <marko(at)joh(dot)to> |
| Cc: | Petr Jelinek <petr(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors |
| Date: | 2014-03-20 15:02:36 |
| Message-ID: | 4055.1395327756@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Marko Tiikkaja <marko(at)joh(dot)to> writes:
> On 3/20/14, 12:32 AM, Tom Lane wrote:
>> 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.
> I'm not sure what exactly you mean by this. If the only allowed values
> are "none", "variable_shadowing" and "all", how is the behaviour for
> those going to change if we make it a list for 9.5?
If we switch to using SplitIdentifierString later, which is the typical
implementation of parsing list GUCs, that will do things like case-fold,
remove double quotes, remove white space. It's possible that that's
completely upward-compatible with what happens if you don't do that ...
but I'm not sure about it.
In any case, if the point of this patch is to provide a framework for
extra error detection, I'm not sure why we'd arbitrarily say we're going
to leave the framework unfinished in the GUC department.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Atri Sharma | 2014-03-20 15:07:11 | Re: Risk Estimation WAS: Planner hints in Postgresql |
| Previous Message | Tom Lane | 2014-03-20 14:45:28 | Re: Risk Estimation WAS: Planner hints in Postgresql |