Josh Berkus <email@example.com> writes: > 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.
You seem to have missed my point, which is that implementation as a new join type would probably have nothing in common with the externally-coded version. The one and only reason for it to be in contrib instead of on pgfoundry is that you think it will get more attention that way. Which might be true, but it's a fairly weak argument for asking the core developers to take on maintenance and bug-fixing for what is ultimately going to be a dead-end code base. This code will either die for lack of interest, or be largely rewritten so it can go into core. I don't pretend to know which will happen, but I see no technical advantage to it being in contrib meanwhile. > 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". [ shrug... ] As an argument for having it in contrib instead of pgfoundry, that impresses me not at all. You could argue that the ability to do this (even poorly) *without* any core code changes is a far greater demonstration of Postgres' basic strength --- namely extensibility --- than it would be in core. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend