From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | UNION JOIN vs UNION SELECT |
Date: | 2000-08-26 23:36:53 |
Message-ID: | 21855.967333013@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I noticed you've got some really ugly stuff in gram.y to handle
SELECT * FROM foo UNION JOIN bar
which has a shift/reduce conflict with
SELECT * FROM foo UNION SELECT * FROM bar
Looks like you resolved this by requiring parens around a UNION JOIN
construct. So, aside from being ugly, this fails to meet the SQL92
spec (nothing about parens there...).
This is another case where a one-token lookahead between the lexer
and parser would make life a lot easier: we could replace UNION JOIN
with a single UNIONJOIN token and thereby eliminate the shift-reduce
conflict.
You'll probably recall that the ambiguity between NOT NULL and NOT
DEFERRABLE gave us similar problems. We were able to get around that
by pretending NOT DEFERRABLE is an independent clause and leaving some
of the parsing work to be done by analyze.c, but I don't think that
trick will work here.
I seem to recall a third case where a lookahead would have helped,
but can't find the details in the archives right now.
I think it's time to bite the bullet and put in a lookahead filter.
What say you?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Juan Carlos Perez Vazquez | 2000-08-26 23:38:00 | Where is the problem? |
Previous Message | Bruce Momjian | 2000-08-26 23:24:43 | Re: Critical server is down, user needs help |