From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, pgsql-patches(at)postgreSQL(dot)org |
Subject: | Re: Doing psql's lexing with flex |
Date: | 2004-02-18 17:42:28 |
Message-ID: | 24510.1077126148@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Feel free (or encouraged) to change the old behavior. (Of course, the
> new behavior needs to adjustments, too.) Generally, I think a variable
> should just stand for a data value and should not result in a slash
> command being generated.
That seems workable for :foo references in the body of a backslash
command --- you can just substitute the value but not allow it to be
split into multiple argument tokens. However, wouldn't you still want
to rescan it for internal :bar references to other variables? The psql
man page has some arm-waving about how you can do indirection, and seems
like that ought to work in this context too.
Also, this seems inconsistent with the non-backslash-command case.
Seems like you have to scan what goes into the query buffer to keep the
lexer state in sync, you can't just treat it as an uninterpreted token.
So not triggering on backslashes seems inconsistent.
We can certainly implement different behavior for the two cases, I'm
just unconvinced we should...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-02-18 18:06:27 | Re: NO WAIT ... |
Previous Message | Peter Eisentraut | 2004-02-18 17:33:59 | Re: Doing psql's lexing with flex |