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 (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers