scan.l: check_escape_warning()

Michael Meskes <meskes@postgresql.org> writes:

could anyone please enlighten me whether this function is still needed?
AFAICT check_escape_warning() only has significant action if
warn_on_first_escape is true. This variable is set to true only on label
xqstart, but to false on xestart. However, check_escape_warning() and
check_string_escape_warning() btw. are only called in mode xe. Seems to
me that both are never called, or what am I missing?

Huh?

regression=# \set VERBOSITY verbose
regression=# select '\002'::text;
WARNING: 22P06: nonstandard use of escape in a string literal
LINE 1: select '\002'::text;
^
HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
LOCATION: check_escape_warning, scan.l:967
text
------
\x02
(1 row)

regression=# select '\\'::text;
WARNING: 22P06: nonstandard use of \\ in a string literal
LINE 1: select '\\'::text;
^
HINT: Use the escape string syntax for backslashes, e.g., E'\\'.
LOCATION: check_string_escape_warning, scan.l:952
text
------
\
(1 row)

Perhaps there's some discrepancy between the ecpg and backend lexers
as to where these are called?

regards, tom lane

Michael Meskes wrote:

Hi,

could anyone please enlighten me whether this function is still needed?
AFAICT check_escape_warning() only has significant action if
warn_on_first_escape is true. This variable is set to true only on label
xqstart, but to false on xestart. However, check_escape_warning() and
check_string_escape_warning() btw. are only called in mode xe. Seems to
me that both are never called, or what am I missing?

What you are missing is that xqstart can lead to mode xe if
standard_conforming_strings is false:

{xqstart} {
warn_on_first_escape = true;
saw_high_bit = false;
SET_YYLLOC();
if (standard_conforming_strings)
BEGIN(xq);
else
BEGIN(xe);
startlit();
}

cheers

andrew

On Fri, Jan 11, 2008 at 10:41:17AM -0500, Tom Lane wrote:

Perhaps there's some discrepancy between the ecpg and backend lexers
as to where these are called?

You're right. There is no way to (un)select standard conforming strings
which makes up for the difference. Thanks for pointing me into the right
direction.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

Michael Meskes <meskes@postgresql.org> writes:

On Fri, Jan 11, 2008 at 10:41:17AM -0500, Tom Lane wrote:

Perhaps there's some discrepancy between the ecpg and backend lexers
as to where these are called?

You're right. There is no way to (un)select standard conforming strings
which makes up for the difference.

If that's how it is going to be, would you remove or #ifdef NOT_USED
the escape_string_warning function? The 'function defined but not used'
warning that it's producing now is kind of annoying ...

regards, tom lane