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