Обсуждение: 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