Обсуждение: scan.l: check_escape_warning()

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?

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:
> 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:967text 
------\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:952text 
------\
(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