On Wed, Jan 21, 2015 at 10:14 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > What I'm inclined to do about this is add an escape_string_warning bool > field to struct core_yy_extra_type, which would be copied from the GUC > variable by scanner_init(); then check_string_escape_warning() would > consult that field instead of consulting the GUC directly. It would > then be possible for fill_in_constant_lengths to reset that field after > calling scanner_init so that no warnings appear during its reparse.
I've noticed this too, and found it annoying. > As a matter of cleanliness I'm inclined to do the same with > backslash_quote and standard_conforming_strings, so that callers of the > core lexer are not tied to using the prevailing GUC settings but can > control all these things. +1 > This isn't a back-patchable bug fix, but given the lack of prior > complaints, maybe it doesn't matter. Alternatively, we could back-patch > only the addition of escape_string_warning to the struct: that would fit > into padding space in the struct so that there would be no ABI risk. > > Comments, objections? I think that this is a good idea, but I see very little reason to back-patch. I'm not aware that the "padding space" argument has been used for something like this before. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
