Tom Lane wrote: > 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?
Agreed. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match