Remove vestigial UNION JOIN support?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Remove vestigial UNION JOIN support?
Дата
Msg-id 13608.1141585984@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Remove vestigial UNION JOIN support?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
SQL92 contains a construct "table1 UNION JOIN table2", which is defined
essentially the same as "table1 FULL JOIN table2 ON false" --- you get
all the rows of table1 null-extended into the table2 columns, and all
the rows of table2 null-extended into the table1 columns, and no actual
join rows.

SQL99, however, deprecates this construct, and it's gone entirely in
SQL2003.  (They don't say *why* they got rid of it --- is it just
because it's redundant, or was there some error in the definition?
Date and Darwen obviously don't like it either, but don't say why.)

We've got some vestigial support for this thing, but given the
subsequent evolution of the standard it seems quite unlikely that
we'll ever finish up the implementation.  It'd make more sense to
spend the work on allowing FULL JOIN ON FALSE, something that we
don't accept today but I think wouldn't be much work to fix.

So I'm proposing that we remove what's there.  In particular we could
get rid of the intermediate yylex() function in parser.c, which should
save at least a few microseconds during every SQL command.  I didn't
have a problem with that function when it was put in, because I figured
we'd find other cases where we needed extra lookahead, but so far we've
not found any so I'm thinking we could save the overhead.

Any objections?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Status of TODO: postgresql.conf: reset to default when
Следующее
От: "Markus Bertheau"
Дата:
Сообщение: pg.conf re-reading in signal handler or at next return to main loop?