Re: [PATCHES] Adding fulldisjunctions to the contrib

Tom,

> The case for FD seems to be basically "if you build it they will come",
> and I'm sorry but I'm not sold.  If it gets some traction as a pgfoundry
> project then we could look at doing a second-generation implementation
> in a form that could actually get into core... but until then I'm
> inclined to see it as an academic curiosity.

I've given my reason for wanting it in another post (data mining and 
conversion).  Let me say this additionally:  full disjunctions is an 
example of the kind of thing we need to have in order to defend our 
title as "the most advanced open source database".   Stuff like 
partitioning and PITR don't cut it anymore ... MySQL and Ingres have 
those.  We need to keep adding innovative features or we lose a great 
deal of our reason for existance as "yet another DBMS", and our ability 
to attract new, smart, original developers.

The reason why it makes sense for FD to be in /contrib is that if it 
works out it will be a new join type, which is definitely core-code stuff.

If QBE were ready, I'd be pushing for that too.  Now, if the statement 
is that FD is too buggy to include in contrib at this time, I'm happy to 
accept that, but I've not seen that argument.

--Josh Berkus