Re: [PATCHES] Adding fulldisjunctions to the contrib - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] Adding fulldisjunctions to the contrib
Date
Msg-id 8439.1155509257@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] Adding fulldisjunctions to the contrib  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] Adding fulldisjunctions to the contrib
Next
From: Tom Lane
Date:
Subject: Re: problem with volatile functions in subselects ?