From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_stat_statements vs escape_string_warning |
Date: | 2015-01-21 18:28:12 |
Message-ID: | CAM3SWZSZtZ2X80ek9EVGRA=rOC7SEPHDw6yOjcKbptyUHfb+kA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 21, 2015 at 10:14 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-01-21 18:37:35 | Re: pg_stat_statements vs escape_string_warning |
Previous Message | Tom Lane | 2015-01-21 18:14:59 | pg_stat_statements vs escape_string_warning |