Peter Eisentraut <pete...@gmx.net> writes:
> Well, I point again to standards_conforming_strings: Leave the warning
> off for one release (or more), then default to on for one (or more),
> then change the behavior.
> We can change the timeline, but I don't think the approach was unsound.
I'm not excited about that approach, for the reasons that were stated
upthread, mainly that there is little reason to think that anybody
paid any attention to the s_c_s transition till they were forced to.
Waiting to make the change will just allow more non-spec-compliant
SQL code to accumulate in the wild, without significantly reducing
the pain involved.
There's one more reason, too: the code I have is designed to give correct
warnings within the context of a parser that parses according to the
spec-compliant rules. It's possible that a similar approach could be used
to generate correct warnings within a parsetree built according to the old
rules, but it would be entirely different in detail and would need a lot
of additional work to develop. I don't particularly want to do that
additional work.
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
