UNION JOIN vs UNION SELECT
От | Tom Lane |
---|---|
Тема | UNION JOIN vs UNION SELECT |
Дата | |
Msg-id | 21855.967333013@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: UNION JOIN vs UNION SELECT
|
Список | pgsql-hackers |
I noticed you've got some really ugly stuff in gram.y to handleSELECT * FROM foo UNION JOIN bar which has a shift/reduce conflict withSELECT * 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
В списке pgsql-hackers по дате отправления: