Обсуждение: scanner/parser for FOREIGN KEY
Hi,
we still need the enhancement of the scanner/parser combo to
enable FOREIGN KEY specification as column constraint (the
due to shift/reduce disabled NOT DEFERRABLE part).
IMHO this must be done before going into BETA. As discussed,
a little token lookup/queueing between lex and yacc can do
the trick. I'd like to add a slightly generic method for it,
so the lookahead function can be reused if we sometimes get
trapped again with a similar problem.
Do we have a consensus to implement it that way now?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
wieck@debis.com (Jan Wieck) writes:
> we still need the enhancement of the scanner/parser combo to
> enable FOREIGN KEY specification as column constraint (the
> due to shift/reduce disabled NOT DEFERRABLE part).
> IMHO this must be done before going into BETA. As discussed,
> a little token lookup/queueing between lex and yacc can do
> the trick. I'd like to add a slightly generic method for it,
> so the lookahead function can be reused if we sometimes get
> trapped again with a similar problem.
> Do we have a consensus to implement it that way now?
AFAIR that was the only concrete solution offered. I think Thomas
wanted to look into whether he could tweak the grammar to avoid the
problem without lookahead, but he hasn't produced any results ---
and I misdoubt that a fix done that way will be any cleaner than
inserting a lexer lookahead interface.
In short, it's fine by me but I dunno if Thomas has signed on yet.
regards, tom lane
Tom Lane wrote:
> wieck@debis.com (Jan Wieck) writes:
> > we still need the enhancement of the scanner/parser combo to
> > enable FOREIGN KEY specification as column constraint (the
> > due to shift/reduce disabled NOT DEFERRABLE part).
> > IMHO this must be done before going into BETA. As discussed,
> > a little token lookup/queueing between lex and yacc can do
> > the trick. I'd like to add a slightly generic method for it,
> > so the lookahead function can be reused if we sometimes get
> > trapped again with a similar problem.
> > Do we have a consensus to implement it that way now?
>
> AFAIR that was the only concrete solution offered. I think Thomas
> wanted to look into whether he could tweak the grammar to avoid the
> problem without lookahead, but he hasn't produced any results ---
> and I misdoubt that a fix done that way will be any cleaner than
> inserting a lexer lookahead interface.
The solution, Thomas suggested, would work too. It will avoid
any portability issues by making analyze.c slightly
complexer, but that's already complex enough by juggling
around with multiple lists, so one more hack there doesn't
count.
> In short, it's fine by me but I dunno if Thomas has signed on yet.
I'm fine with either solution. IMHO it's just a MUST BE THERE
before going BETA, since it affects the syntax of the query
language.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> AFAIR that was the only concrete solution offered. I think Thomas
> wanted to look into whether he could tweak the grammar to avoid the
> problem without lookahead, but he hasn't produced any results ---
> and I misdoubt that a fix done that way will be any cleaner than
> inserting a lexer lookahead interface.
> In short, it's fine by me but I dunno if Thomas has signed on yet.
I glanced at it, but have not had a chance to dive in. There had been
so many changes to the parser code while I was off playing with outer
join syntax that I decided to start over (lots of what I had done
needed to be cleaned up anyway).
I hope to get back to development within a few days, but in the
meantime my parser is re-broken and I haven't yet fixed Jan's parts. I
hate to be holding up Jan, but otoh I hate to see us having to use a
new techique for parsing if the usual ones can be made to work...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> > AFAIR that was the only concrete solution offered. I think Thomas > > wanted to look into whether he could tweak the grammar to avoid the > > problem without lookahead, but he hasn't produced any results --- > > and I misdoubt that a fix done that way will be any cleaner than > > inserting a lexer lookahead interface. > > In short, it's fine by me but I dunno if Thomas has signed on yet. > > I glanced at it, but have not had a chance to dive in. There had been > so many changes to the parser code while I was off playing with outer > join syntax that I decided to start over (lots of what I had done > needed to be cleaned up anyway). > > I hope to get back to development within a few days, but in the > meantime my parser is re-broken and I haven't yet fixed Jan's parts. I > hate to be holding up Jan, but otoh I hate to see us having to use a > new techique for parsing if the usual ones can be made to work... Agreed. Maybe Thomas and I can get on the phone and hammer out a fix. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026