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 thin
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 that
Tom Lane wrote:
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 ho
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 whe
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 j
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
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 parsing ends
and lexing begins. Anyone care
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 w
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 we
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
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
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 $$ seems questio
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 beli
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 implementati
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 | Modifie
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 wor
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 stri
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, i
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:
> 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 t
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
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] &
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:
> +
23 matches
Mail list logo
