Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> "Character 1" is correct as of the context that the parser is working
>> in, namely the function body. I don't think we can do much to change
>> that, but perhaps we could make the message read like
>> ERROR: parser: parse error
Tom Lane writes:
> "Character 1" is correct as of the context that the parser is working
> in, namely the function body. I don't think we can do much to change
> that, but perhaps we could make the message read like
> ERROR: parser: parse error at or near "not" at character 1 of function body
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Reworking the code to taken into account token_start seems to work.
Yes, I did that last night ...
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive
On Sun, 18 Aug 2002, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > In strings.sql:
>
> > -- illegal string continuation syntax
> > SELECT 'first line'
> > ' - next line' /* this comment is not allowed here */
> > ' - third line'
> > AS "Illegal comment within continu
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> In strings.sql:
> -- illegal string continuation syntax
> SELECT 'first line'
> ' - next line' /* this comment is not allowed here */
> ' - third line'
> AS "Illegal comment within continuation";
> ERROR: parser: parse error at or near "' -
Gavin Sherry writes:
> In that case, attached is a patch which locates the beginning of the
> offending token more efficiently (per your suggestion of using
> scanbuf).
In the regression tests there are a couple of cases that could be
improved:
In strings.sql:
-- illegal string continuation sy
