Parsing is a whole nother ball of wax besides lexing. I wasn't planning
to put *that* into psql. Remember the only thing psql really wants from
this is to detect where end-of-statement is ...
OK, I'm not that great at understanding where lexing ands and parsing
starts. These are the things
Doh, sorry. I just realised that the lists just gave me a whole bunch
of mails from back in February, which is when Tom made this post...
Chris
Christopher Kings-Lynne wrote:
Parsing is a whole nother ball of wax besides lexing. I wasn't planning
to put *that* into psql. Remember the only
Bruce Momjian wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
No, it won't. The problem is that it should, because the backend will
see that as '42' followed by a $foo$ quote start.
Ok, I see what you are saying. This mismatch would only happen on
invalid input,
Andrew Dunstan [EMAIL PROTECTED] writes:
I'd be surprised if using a flex lexer instead made a huge speed
difference, but maybe I'm wrong.
No, I agree --- it's unlikely to make very much difference in the real
world. Maybe on huge query strings you could notice the difference.
I'm more
Actually, I thought the way to handle it would be to duplicate the
backend lexer as nearly as possible. Most of the productions would have
empty bodies probably, but doing it that way would guarantee that in
fact psql and the backend would lex a string the same way, which is
exactly the problem
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
You know what would be really sweet? If the lexing was made available
as a public function. eg. So I could parse queries in phpPgAdmin before
sending them to the backend, etc...
Parsing is a whole nother ball of wax besides lexing. I
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
No, it won't. The problem is that it should, because the backend will
see that as '42' followed by a $foo$ quote start.
Ok, I see what you are saying. This mismatch would only happen on
invalid input, though. I believe that what
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Parsing is a whole nother ball of wax besides lexing.
Forgive my lameness, but I've never truly figured out where parsing ends
and lexing begins. Anyone care to illuminate me on the difference?
The theoretical answer is that you can do
Christopher Kings-Lynne wrote:
Parsing is a whole nother ball of wax besides lexing. I wasn't planning
to put *that* into psql. Remember the only thing psql really wants from
this is to detect where end-of-statement is ...
Forgive my lameness, but I've never truly figured out where
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am a little concerned about adding the overhead of lex to psql. Right
now, some folks have reported that lex/yacc take a considerable amount
of processing time in the backend as part of a query, and adding that to
psql just to do
Another interesting thing abut psql that I noticed when using '$' in
identifiers is this effect:
andrew=# create table ab$cd$ef (ef$cd$ab text);
CREATE TABLE
andrew=# \d ab$cd$ef
Did not find any relation named ab$cd$ef.
andrew=# \d ab\$cd\$ef
Table public.ab$cd$ef
Column | Type | Modifiers
Andrew Dunstan [EMAIL PROTECTED] writes:
andrew=# create table ab$cd$ef (ef$cd$ab text);
CREATE TABLE
andrew=# \d ab$cd$ef
Did not find any relation named ab$cd$ef.
Hmph. I always thought that $ was only special at the end of a regex,
but that doesn't seem to be how our implementation treats
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
... But how about
42$foo$
This is a syntax error in 7.4, and we propose to redefine it as an
integer literal '42' followed by a dollar-quote start symbol.
The test should not succeed anywhere in the
Andrew Dunstan [EMAIL PROTECTED] writes:
No, it won't. The problem is that it should, because the backend will
see that as '42' followed by a $foo$ quote start.
Ok, I see what you are saying. This mismatch would only happen on
invalid input, though. I believe that what I did will work on
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I ended up not using a regex, which seemed to be a little heavy handed,
but just writing a small custom recognition function, that should (and I
think does) mimic the pattern recognition for these tokens used by the
backend lexer.
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
... But how about
42$foo$
This is a syntax error in 7.4, and we propose to redefine it as an
integer literal '42' followed by a dollar-quote start symbol.
The test should not succeed anywhere in the string '42$foo$'.
No, it won't.
Andrew Dunstan [EMAIL PROTECTED] writes:
I ended up not using a regex, which seemed to be a little heavy handed,
but just writing a small custom recognition function, that should (and I
think does) mimic the pattern recognition for these tokens used by the
backend lexer.
I looked at this
Tom Lane wrote:
A bigger problem here:
+ else if (!dol_quote line[i] == '$'
+ !isdigit(line[i + thislen])
+ (dol_end = strchr(line+i+1,'$')) != NULL
+ (i == 0 ||
+ ! ((line[i-1] 0x80) !=
I think the attached patch addresses Tom's comments.
I ended up not using a regex, which seemed to be a little heavy handed,
but just writing a small custom recognition function, that should (and I
think does) mimic the pattern recognition for these tokens used by the
backend lexer. This patch
Andrew Dunstan [EMAIL PROTECTED] writes:
Comments welcome. Reviewers: I am not sure I got multi-byte stuff right
in psql/mainloop.c - please pay close attention to that.
The i-1 stuff should generally be i-prevlen. Not sure if there are any
other pitfalls.
A bigger problem here:
+
20 matches
Mail list logo
