Marko Tiikkaja <ma...@joh.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
