Tom,
> Could we see a concrete, real-world example? So far I've seen a lot of
> arm-waving but nothing very specific.
Sure. Imagine that you work for an arts nonprofit and you have 3 (or more)
separate box office lists from last season, each of which has different
amounts of contact information. You want to get "best of" the information
-- that is, address if it's available, zip if it's there, phone if it's
there, etc. FD will reduce that process from several procedural loops
to a single query for the first pre-deduplication run.
Or, imagine that you have 5 weblogs in different formats from 5 different
servers. Due to the different logging/site design, you have and lack
different information from each log. You want to munge all of the data
together to extract the maximum amount of data about each visitor you can
get, without having multiple records per visit.
This supposition holds true for court records, customer records, etc ...
anywhere you may have relational data with a high degree of incompleteness
from different sources ... something I encountered on about 30% of all the
DB development projects I worked on.
> 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.
OK, point taken. I'll admit that I had hopes for it for PR reasons, which
is not usually why we make decisions. It would be cool to be the first
database system to ship with any implementation of Full Disjunctions, and
I can't announce that if it's on pgFoundry.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco