On Wed, Jan 21, 2015 at 10:14 AM, Tom Lane <tgl@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