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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to