Re: [PATCHES] Adding fulldisjunctions to the contrib

Hi,
I wish to add the fulldisjunctions function to the contrib.
With the help of Jonah, we (or rather he :) created a patch with
regression tests. The function is finished programmatically but
still a little more code documentation touches and improved error messages
are needed. All the rest was extensively tested.

Attached is the patch.

Works great. Just compiled from a fresh cvs which i patched with the
attached diff. ran the fulldijsjunction.sql in the
share/contrib/fulldisjunction and let it run and it works great.
10x.

--
Regards,
        Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
WARNING TO SPAMMERS:  see at
http://members.lycos.co.uk/my2nis/spamwarning.html

I have looked over this addition, and I think I finally understand it.
Given three tables, A, B, C, which join as A->B, B->C, C->A, you can
really join them as A->B->C, and A->C->B. What full disjunction does is
to perform both of those joins, and return a one row for each join. Here
is an example from the README:

Example of an input and output of a full disjunctions:
INPUT:

--A---|---B---|---C--
X---Y-|-Y---Z-|-X---Z
a-|-b-|-b-|-c-|-a-|-d

A,B and C are relations. X,Y and Z are attributes. a,b,c and d are values.

Note that A,B and C are connected in a cycle. That is:
A is connected to B on attribute Y,
B is connected to C on attribute Z,
C is connected to A on attribute X.

The output of the full disjunctions FD(A,B,C):

FD
X---Y---Z
a-|-b-|-c
a-|-b-|-d

This code is pretty complex, so I can see why it should be in /contrib.
Are there reasonable use cases for this capability?

---------------------------------------------------------------------------

Tzahi Fadida wrote:
> Hi,
> I wish to add the fulldisjunctions function to the contrib.
> With the help of Jonah, we (or rather he :) created a patch with
> regression tests. The function is finished programmatically but
> still a little more code documentation touches and improved error messages
> are needed. All the rest was extensively tested.
>
> Attached is the patch.
>
> Works great. Just compiled from a fresh cvs which i patched with the
> attached diff. ran the fulldijsjunction.sql in the
> share/contrib/fulldisjunction and let it run and it works great.
> 10x.
>
> --
> Regards,
> ????????Tzahi.
> --
> Tzahi Fadida
> Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
> WARNING TO SPAMMERS: ?see at
> http://members.lycos.co.uk/my2nis/spamwarning.html

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Friday 11 August 2006 07:18, Bruce Momjian wrote:
> I have looked over this addition, and I think I finally understand it.
> Given three tables, A, B, C, which join as A->B, B->C, C->A, you can
> really join them as A->B->C, and A->C->B. What full disjunction does is
> to perform both of those joins, and return a one row for each join. Here

What it does is to return all the possible natural joins, i.e.:
A
B
C
A,B
A,C
...
A,B,C

And, it removes any redundant information so that if we have a tuple
that already contains another tuple's information that tuple is discarded.
Also, note that the full disjunction algorithm i implemented
is commonly used in cases where the scheme graph is cyclic
and thus, you cannot use natural full outer join
to compute the FD.

Finally, you can FD(A,B,C,D,...) any number of relations (limited to 32 in
the implementation) with no regard to the order between them.

A case study and comparison can be found here:
http://www.technion.ac.il/~tzahi/soc.html

> is an example from the README:
>
> Example of an input and output of a full disjunctions:
> INPUT:
>
> --A---|---B---|---C--
> X---Y-|-Y---Z-|-X---Z
> a-|-b-|-b-|-c-|-a-|-d
>
> A,B and C are relations. X,Y and Z are attributes. a,b,c and d are
> values.
>
> Note that A,B and C are connected in a cycle. That is:
> A is connected to B on attribute Y,
> B is connected to C on attribute Z,
> C is connected to A on attribute X.
>
> The output of the full disjunctions FD(A,B,C):
>
> FD
> X---Y---Z
> a-|-b-|-c
> a-|-b-|-d
>
> This code is pretty complex, so I can see why it should be in /contrib.
> Are there reasonable use cases for this capability?
>
> ---------------------------------------------------------------------------
>
> Tzahi Fadida wrote:
> > Hi,
> > I wish to add the fulldisjunctions function to the contrib.
> > With the help of Jonah, we (or rather he :) created a patch with
> > regression tests. The function is finished programmatically but
> > still a little more code documentation touches and improved error
> > messages are needed. All the rest was extensively tested.
> >
> > Attached is the patch.
> >
> > Works great. Just compiled from a fresh cvs which i patched with the
> > attached diff. ran the fulldijsjunction.sql in the
> > share/contrib/fulldisjunction and let it run and it works great.
> > 10x.
> >
> > --
> > Regards,
> > ????????Tzahi.
> > --
> > Tzahi Fadida
> > Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
> > WARNING TO SPAMMERS: ?see at
> > http://members.lycos.co.uk/my2nis/spamwarning.html
>
> [ Attachment, skipping... ]
>
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/docs/faq

--
Regards,
        Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
WARNING TO SPAMMERS:  see at
http://members.lycos.co.uk/my2nis/spamwarning.html

I am still waiting for someone to tell us that they would use this
capability for a real-world problem.

---------------------------------------------------------------------------

Tzahi Fadida wrote:
> On Friday 11 August 2006 07:18, Bruce Momjian wrote:
> > I have looked over this addition, and I think I finally understand it.
> > Given three tables, A, B, C, which join as A->B, B->C, C->A, you can
> > really join them as A->B->C, and A->C->B. What full disjunction does is
> > to perform both of those joins, and return a one row for each join. Here
>
> What it does is to return all the possible natural joins, i.e.:
> A
> B
> C
> A,B
> A,C
> ...
> A,B,C
>
> And, it removes any redundant information so that if we have a tuple
> that already contains another tuple's information that tuple is discarded.
> Also, note that the full disjunction algorithm i implemented
> is commonly used in cases where the scheme graph is cyclic
> and thus, you cannot use natural full outer join
> to compute the FD.
>
> Finally, you can FD(A,B,C,D,...) any number of relations (limited to 32 in
> the implementation) with no regard to the order between them.
>
> A case study and comparison can be found here:
> http://www.technion.ac.il/~tzahi/soc.html
>
> > is an example from the README:
> >
> > Example of an input and output of a full disjunctions:
> > INPUT:
> >
> > --A---|---B---|---C--
> > X---Y-|-Y---Z-|-X---Z
> > a-|-b-|-b-|-c-|-a-|-d
> >
> > A,B and C are relations. X,Y and Z are attributes. a,b,c and d are
> > values.
> >
> > Note that A,B and C are connected in a cycle. That is:
> > A is connected to B on attribute Y,
> > B is connected to C on attribute Z,
> > C is connected to A on attribute X.
> >
> > The output of the full disjunctions FD(A,B,C):
> >
> > FD
> > X---Y---Z
> > a-|-b-|-c
> > a-|-b-|-d
> >
> > This code is pretty complex, so I can see why it should be in /contrib.
> > Are there reasonable use cases for this capability?
> >
> > ---------------------------------------------------------------------------
> >
> > Tzahi Fadida wrote:
> > > Hi,
> > > I wish to add the fulldisjunctions function to the contrib.
> > > With the help of Jonah, we (or rather he :) created a patch with
> > > regression tests. The function is finished programmatically but
> > > still a little more code documentation touches and improved error
> > > messages are needed. All the rest was extensively tested.
> > >
> > > Attached is the patch.
> > >
> > > Works great. Just compiled from a fresh cvs which i patched with the
> > > attached diff. ran the fulldijsjunction.sql in the
> > > share/contrib/fulldisjunction and let it run and it works great.
> > > 10x.
> > >
> > > --
> > > Regards,
> > > ????????Tzahi.
> > > --
> > > Tzahi Fadida
> > > Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
> > > WARNING TO SPAMMERS: ?see at
> > > http://members.lycos.co.uk/my2nis/spamwarning.html
> >
> > [ Attachment, skipping... ]
> >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 3: Have you checked our extensive FAQ?
> > >
> > > http://www.postgresql.org/docs/faq
>
> --
> Regards,
> ????????Tzahi.
> --
> Tzahi Fadida
> Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
> WARNING TO SPAMMERS: ?see at
> http://members.lycos.co.uk/my2nis/spamwarning.html

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Saturday 12 August 2006 07:22, Bruce Momjian wrote:
> I am still waiting for someone to tell us that they would use this
> capability for a real-world problem.

I suggest looking into web applications.
The example here
http://www.technion.ac.il/~tzahi/soc.html

shows a possible 3 separate web resources.
I.e. heterogeneous sources. Naturally, since the sources
did not know each other in advance, they did not form
relations that would not end up cyclic in the scheme graph.
XMLs are usually like these. Obviously you have to turn them into
relations first of course.
In addition, i have recently added a feature where you give alias to column
names so if you have "country" column and a "state" column that really means
country, you can do "country=public.relation_with_state.state,..." dictionary
style. This is commonly needed in web applications.

Here is another example (improvising :) ):
site1: user_name,email,favorite_book_isbn
site2: user_name,email,favorite_chat_room
site3: user_name,credit_card

So, let's say i wanted to advertise discounts using a certain credit card
for certain books, i would do FD(site1,site2,site3).
Natural join will give - so you get data on people who read some books and
visit certain chat rooms and users credit cards.
FD will give - some people did not buy books but have a credit card and a
chat room so you want to advertise anyway.
Some people did buy books and uses
a certain credit cards but you don't know where they chat, however,
you know you want to adv some best seller that most buy anyway.
certain people did buy books and visit chat rooms but you can't offer
a specific discount, so you will advertise all credit cards.
...

However, caution. FD is a very,very expensive operation even with the new
algorithms so it is best to do FD separately and put the results into a table
and use that table. Unless of course, as common to web applications, the
relations are quite small (few thousands of rows) and they don't connect
strongly. In this cases, on my p1.6 it comes out about 2-3 secs.
However, i can generate the same experiment with strong connectivity
between the relations and it can take hours to compute.
On the other hand i have seen experiments with 100 thousans of records
that finished in a matter of minutes so it all depends on how many join
combination there are in the data.

>
> ---------------------------------------------------------------------------
>
> Tzahi Fadida wrote:
> > On Friday 11 August 2006 07:18, Bruce Momjian wrote:
> > > I have looked over this addition, and I think I finally understand it.
> > > Given three tables, A, B, C, which join as A->B, B->C, C->A, you can
> > > really join them as A->B->C, and A->C->B. What full disjunction does
> > > is to perform both of those joins, and return a one row for each join.
> > > Here
> >
> > What it does is to return all the possible natural joins, i.e.:
> > A
> > B
> > C
> > A,B
> > A,C
> > ...
> > A,B,C
> >
> > And, it removes any redundant information so that if we have a tuple
> > that already contains another tuple's information that tuple is
> > discarded. Also, note that the full disjunction algorithm i implemented
> > is commonly used in cases where the scheme graph is cyclic
> > and thus, you cannot use natural full outer join
> > to compute the FD.
> >
> > Finally, you can FD(A,B,C,D,...) any number of relations (limited to 32
> > in the implementation) with no regard to the order between them.
> >
> > A case study and comparison can be found here:
> > http://www.technion.ac.il/~tzahi/soc.html
> >
> > > is an example from the README:
> > >
> > > Example of an input and output of a full disjunctions:
> > > INPUT:
> > >
> > > --A---|---B---|---C--
> > > X---Y-|-Y---Z-|-X---Z
> > > a-|-b-|-b-|-c-|-a-|-d
> > >
> > > A,B and C are relations. X,Y and Z are attributes. a,b,c and d are
> > > values.
> > >
> > > Note that A,B and C are connected in a cycle. That is:
> > > A is connected to B on attribute Y,
> > > B is connected to C on attribute Z,
> > > C is connected to A on attribute X.
> > >
> > > The output of the full disjunctions FD(A,B,C):
> > >
> > > FD
> > > X---Y---Z
> > > a-|-b-|-c
> > > a-|-b-|-d
> > >
> > > This code is pretty complex, so I can see why it should be in /contrib.
> > > Are there reasonable use cases for this capability?
> > >
> > > -----------------------------------------------------------------------
> > >----
> > >
> > > Tzahi Fadida wrote:
> > > > Hi,
> > > > I wish to add the fulldisjunctions function to the contrib.
> > > > With the help of Jonah, we (or rather he :) created a patch with
> > > > regression tests. The function is finished programmatically but
> > > > still a little more code documentation touches and improved error
> > > > messages are needed. All the rest was extensively tested.
> > > >
> > > > Attached is the patch.
> > > >
> > > > Works great. Just compiled from a fresh cvs which i patched with the
> > > > attached diff. ran the fulldijsjunction.sql in the
> > > > share/contrib/fulldisjunction and let it run and it works great.
> > > > 10x.
> > > >
> > > > --
> > > > Regards,
> > > > ????????Tzahi.
> > > > --
> > > > Tzahi Fadida
> > > > Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
> > > > WARNING TO SPAMMERS: ?see at
> > > > http://members.lycos.co.uk/my2nis/spamwarning.html
> > >
> > > [ Attachment, skipping... ]
> > >
> > > > ---------------------------(end of
> > > > broadcast)--------------------------- TIP 3: Have you checked our
> > > > extensive FAQ?
> > > >
> > > > http://www.postgresql.org/docs/faq
> >
> > --
> > Regards,
> > ????????Tzahi.
> > --
> > Tzahi Fadida
> > Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
> > WARNING TO SPAMMERS: ?see at
> > http://members.lycos.co.uk/my2nis/spamwarning.html

--
Regards,
        Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
WARNING TO SPAMMERS:  see at
http://members.lycos.co.uk/my2nis/spamwarning.html

On Aug 12, 2006, at 6:01 , Tzahi Fadida wrote:

> On Saturday 12 August 2006 07:22, Bruce Momjian wrote:
>> I am still waiting for someone to tell us that they would use this
>> capability for a real-world problem.

Notice that if you google "full disjunction" that the first link is
this project.

You won't find anyone to vouch for it because this is the first
implementation of full disjunctions in any database. That doesn't
mean it isn't useful- it means no one is using it because it hasn't
existed until now.

This is the point where one needs to decide whether PostgreSQL is a
copier of features from other databases or whether it can lead with a
few unique features of its own.

AgentM wrote:
>
> On Aug 12, 2006, at 6:01 , Tzahi Fadida wrote:
>
> > On Saturday 12 August 2006 07:22, Bruce Momjian wrote:
> >> I am still waiting for someone to tell us that they would use this
> >> capability for a real-world problem.
>
> Notice that if you google "full disjunction" that the first link is
> this project.
>
> You won't find anyone to vouch for it because this is the first
> implementation of full disjunctions in any database. That doesn't
> mean it isn't useful- it means no one is using it because it hasn't
> existed until now.
>
> This is the point where one needs to decide whether PostgreSQL is a
> copier of features from other databases or whether it can lead with a
> few unique features of its own.

OK, that is helpful. Now, does any current user think they will use
full disjunctions? Is that a fair question?

The point is not whether it should work with PostgreSQL, but whether we
ship it in /contrib, or it is on pgfoundry.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

AgentM <agentm(at)themactionfaction(dot)com> writes:
> You won't find anyone to vouch for it because this is the first
> implementation of full disjunctions in any database. That doesn't
> mean it isn't useful- it means no one is using it because it hasn't
> existed until now.

> This is the point where one needs to decide whether PostgreSQL is a
> copier of features from other databases or whether it can lead with a
> few unique features of its own.

Somewhere along here we need to remember that "most new ideas are bad".

More seriously: the current state of affairs is that the
full-disjunction code exists as a pgfoundry project. If it's indeed the
second greatest thing since sliced bread, then I think we could assume
that people will find it and use it from pgfoundry. The question that's
on the table is whether it needs to be in contrib right now. I have not
seen either a technical argument or popularity argument why it ought to
move into contrib.

regards, tom lane

On 8/12/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> More seriously: the current state of affairs is that the
> full-disjunction code exists as a pgfoundry project. If it's indeed the
> second greatest thing since sliced bread, then I think we could assume
> that people will find it and use it from pgfoundry.

That goes back to assuming people not only know about pgfoundry, but
are similarly willing to search it.

> The question that's on the table is whether it needs to be in contrib right now.
> I have not seen either a technical argument or popularity argument why it
> ought to move into contrib.

In addition to knowing that Tzahi has put a *very* significant amount
of work into his research as well as this code over the past few
months, I have to agree with several items stated by "Agent M".

This is the *first* implementation of this concept in any database
system, so there's not going to be anyone jumping up and down singing
it's praises just yet. However, when people do get a chance to play
with it, I believe we'll have a number of them saying how useful it
is. There are several contrib modules still included in the system
that aren't that heavily used... I don't see the harm in including
this one for at least this release. If no one uses it, take it out
for 8.3.

IMHO, this is just a really cool piece of technology that provides
functionality which can't be done any other way; why not give it a
chance?

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

Jonah H. Harris wrote:
> On 8/12/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > More seriously: the current state of affairs is that the
> > full-disjunction code exists as a pgfoundry project. If it's indeed the
> > second greatest thing since sliced bread, then I think we could assume
> > that people will find it and use it from pgfoundry.
>
> That goes back to assuming people not only know about pgfoundry, but
> are similarly willing to search it.
>
> > The question that's on the table is whether it needs to be in contrib right now.
> > I have not seen either a technical argument or popularity argument why it
> > ought to move into contrib.
>
> In addition to knowing that Tzahi has put a *very* significant amount
> of work into his research as well as this code over the past few
> months, I have to agree with several items stated by "Agent M".
>
> This is the *first* implementation of this concept in any database
> system, so there's not going to be anyone jumping up and down singing
> it's praises just yet. However, when people do get a chance to play
> with it, I believe we'll have a number of them saying how useful it
> is. There are several contrib modules still included in the system
> that aren't that heavily used... I don't see the harm in including
> this one for at least this release. If no one uses it, take it out
> for 8.3.
>
> IMHO, this is just a really cool piece of technology that provides
> functionality which can't be done any other way; why not give it a
> chance?

Our distribution is not a place to experiment with things. That's what
separate pgfoundry projects are for. The fact we have some unusual
things in /contrib is not a reason to add more.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Sun, Aug 13, 2006 at 10:07:06AM -0400, Bruce Momjian wrote:
> Jonah H. Harris wrote:
> > On 8/12/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > More seriously: the current state of affairs is that the
> > > full-disjunction code exists as a pgfoundry project. If it's
> > > indeed the second greatest thing since sliced bread, then I
> > > think we could assume that people will find it and use it from
> > > pgfoundry.
> >
> > That goes back to assuming people not only know about pgfoundry,
> > but are similarly willing to search it.
> >
> > > The question that's on the table is whether it needs to be in
> > > contrib right now. I have not seen either a technical argument
> > > or popularity argument why it ought to move into contrib.
> >
> > In addition to knowing that Tzahi has put a *very* significant
> > amount of work into his research as well as this code over the
> > past few months, I have to agree with several items stated by
> > "Agent M".
> >
> > This is the *first* implementation of this concept in any database
> > system, so there's not going to be anyone jumping up and down
> > singing it's praises just yet. However, when people do get a
> > chance to play with it, I believe we'll have a number of them
> > saying how useful it is. There are several contrib modules still
> > included in the system that aren't that heavily used... I don't
> > see the harm in including this one for at least this release. If
> > no one uses it, take it out for 8.3.
> >
> > IMHO, this is just a really cool piece of technology that provides
> > functionality which can't be done any other way; why not give it a
> > chance?
>
> Our distribution is not a place to experiment with things. That's
> what separate pgfoundry projects are for. The fact we have some
> unusual things in /contrib is not a reason to add more.

If it's on track to become part of PostgreSQL, as other innovative
features have in the past, it very much does belong there. Why
marginalize the very thing that PostgreSQL is really good
at--innovative new features--by putting it somewhere where few people
will ever even see it?

If there were some very, very clear language every place a person
could download, check references, or install PostgreSQL that new
experimental features are at pgFoundry, that might be different. As
it is, you have to be truly dedicated even to discover that pgFoundry
exists.

Let's get full disjunctions in contrib with a good README and have
people figure out what to do with them from there. If no one demands
full inclusion in a couple of versions, let's take it out.

Cheers,
D
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!

David Fetter wrote:
> > Our distribution is not a place to experiment with things. That's
> > what separate pgfoundry projects are for. The fact we have some
> > unusual things in /contrib is not a reason to add more.
>
> If it's on track to become part of PostgreSQL, as other innovative
> features have in the past, it very much does belong there. Why
> marginalize the very thing that PostgreSQL is really good
> at--innovative new features--by putting it somewhere where few people
> will ever even see it?
>
> If there were some very, very clear language every place a person
> could download, check references, or install PostgreSQL that new
> experimental features are at pgFoundry, that might be different. As
> it is, you have to be truly dedicated even to discover that pgFoundry
> exists.
>
> Let's get full disjunctions in contrib with a good README and have
> people figure out what to do with them from there. If no one demands
> full inclusion in a couple of versions, let's take it out.

Where does it stop, then? Do we have everything in /contrib. I don't
see how this scales. When we took the code from Berkely, it had
everyone's doctoral thesis in there, and we had to remove alot of it
because it was just too messy.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Sun, Aug 13, 2006 at 11:45:43AM -0400, Bruce Momjian wrote:
> David Fetter wrote:
> > > Our distribution is not a place to experiment with things.
> > > That's what separate pgfoundry projects are for. The fact we
> > > have some unusual things in /contrib is not a reason to add
> > > more.
> >
> > If it's on track to become part of PostgreSQL, as other innovative
> > features have in the past, it very much does belong there. Why
> > marginalize the very thing that PostgreSQL is really good
> > at--innovative new features--by putting it somewhere where few
> > people will ever even see it?
> >
> > If there were some very, very clear language every place a person
> > could download, check references, or install PostgreSQL that new
> > experimental features are at pgFoundry, that might be different.
> > As it is, you have to be truly dedicated even to discover that
> > pgFoundry exists.
> >
> > Let's get full disjunctions in contrib with a good README and have
> > people figure out what to do with them from there. If no one
> > demands full inclusion in a couple of versions, let's take it out.
>
> Where does it stop, then? Do we have everything in /contrib. I
> don't see how this scales. When we took the code from Berkely, it
> had everyone's doctoral thesis in there, and we had to remove alot
> of it because it was just too messy.

If it were just me laying out the boundary, I'd say that anything that
changes the grammar of SQL--for example, adding FULL
DISJUNCTION--can't really be a viable trial outside the main
distribution channels and deserves a couple of versions' stay in one
of those channels if it passes the scrutiny of -hackers. I'd love to
see a "main distribution channel" that's not contrib, but that's for
the future and full disjunctions are now. :)

Cheers,
D
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!

"Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:
> I don't see the harm in including this one for at least this release.
> If no one uses it, take it out for 8.3.

Once stuff is in contrib, it tends to stay there. The above argument
is completely disingenuous --- we'd have to have the same argument
again at the end of the 8.3 cycle, only then we'd already have expended
a development cycle's worth of maintenance work on a quite-large module.

There is quite a lot of stuff in contrib that the core committee
wouldn't accept nowadays ... it got in when there wasn't any alternative
such as pgfoundry. These days I think something has to be pretty
clearly useful to a wide variety of people before we'll accept it into
contrib, and I'm not seeing that that case has been made for
fulldisjunctions. FD may be cool, but coolness isn't a (sufficient)
criterion.

regards, tom lane

David Fetter wrote:
> If it were just me laying out the boundary, I'd say that anything that
> changes the grammar of SQL--for example, adding FULL
> DISJUNCTION--can't really be a viable trial outside the main
> distribution channels and deserves a couple of versions' stay in one
> of those channels if it passes the scrutiny of -hackers. I'd love to
> see a "main distribution channel" that's not contrib, but that's for
> the future and full disjunctions are now. :)
>
>
>

As I understand it, FD as implemented does not require a grammar change.
Arguably, a more complete implementation would have support at the SQL
level, and then it would have to go in core, without question.

cheers

andrew

David Fetter <david(at)fetter(dot)org> writes:
> If it were just me laying out the boundary, I'd say that anything that
> changes the grammar of SQL--for example, adding FULL
> DISJUNCTION--can't really be a viable trial outside the main
> distribution channels and deserves a couple of versions' stay in one
> of those channels if it passes the scrutiny of -hackers.

Well, one of the things I don't especially like about this patch is
exactly that it doesn't change the grammar (it can't really, as a
contrib module :-(). There's no way that it would get into core without
a different API and probably a complete code rewrite. So what we've got
here, at bottom, is a toy prototype that might serve for people to
experiment with the feature and find out whether it's useful or not ---
but it's not code that could be mainstream with just a bit more
maturity.

Perhaps contrib/dblink is a useful comparison point; that code will
never get into core in its current form either. The reason it's in
contrib is that the use-case is so compelling that we're willing to
accept it even though we all know it's pretty klugy.

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.

regards, tom lane

Bruce Momjian wrote:
> I am still waiting for someone to tell us that they would use this
> capability for a real-world problem.

It's extremely useful for data mining and data consolidation where
you're given messy or sparse data to "clean up" and present intelligently.

For example, if it had existed 4 years ago, I would have used it for
importing ELBS data from the UDF table (with lots of null rows) into
PostgreSQL.

--Josh

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

On 8/13/06, Josh Berkus <josh(at)agliodbs(dot)com> wrote:

My sentiments exactly.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Bruce Momjian wrote:
>> I am still waiting for someone to tell us that they would use this
>> capability for a real-world problem.

> It's extremely useful for data mining and data consolidation where
> you're given messy or sparse data to "clean up" and present intelligently.

Could we see a concrete, real-world example? So far I've seen a lot of
arm-waving but nothing very specific.

regards, tom lane

Josh Berkus <josh(at)agliodbs(dot)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

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

Josh Berkus wrote:
> 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.
>
>

I don't see that having it on pgfoundry makes it less announceable. But
if/when we get support at the SQL level, then we'll *really* have
something worth announcing.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Josh Berkus wrote:
>> 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.

> I don't see that having it on pgfoundry makes it less announceable. But
> if/when we get support at the SQL level, then we'll *really* have
> something worth announcing.

I think Andrew's first point here is spot-on. We *must* take pgfoundry
seriously as part of the available technology for Postgres. Otherwise
all the effort we've put into building up pgfoundry (and gborg before it)
was a waste of time. Are Perl modules taken less seriously because
they're on CPAN rather than part of the minimal Perl distribution?
No, they're not. That is the model that we've got to strive for,
because the core developers simply haven't got enough cycles to deal
with core Postgres development and the entire kitchen sink as well.

This is not just a matter of core-developer laziness, either. The
concept of a cloud of useful code around a small core is something
I think is absolutely critical to PG's long-term success. We have
a built-in advantage here because of PG's historical commitment to
extensibility. Can you see Oracle, DB2, or MySQL operating that way?
No, you can't, because their core code is not open, or they have a
business need to control everything going on, or both.

We need to *exploit* our ability to support important outside-the-core
projects. Not assume that anything outside core can't be important.

regards, tom lane

> 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.
>
>
You could announce it as an available module however.

Joshua D. Drake

Sorry, we did not get enough feedback to include this in 8.2. Please
add it to pgfoundry and let's see how it goes.

---------------------------------------------------------------------------

Tzahi Fadida wrote:
> Hi,
> I wish to add the fulldisjunctions function to the contrib.
> With the help of Jonah, we (or rather he :) created a patch with
> regression tests. The function is finished programmatically but
> still a little more code documentation touches and improved error messages
> are needed. All the rest was extensively tested.
>
> Attached is the patch.
>
> Works great. Just compiled from a fresh cvs which i patched with the
> attached diff. ran the fulldijsjunction.sql in the
> share/contrib/fulldisjunction and let it run and it works great.
> 10x.
>
> --
> Regards,
> ????????Tzahi.
> --
> Tzahi Fadida
> Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
> WARNING TO SPAMMERS: ?see at
> http://members.lycos.co.uk/my2nis/spamwarning.html

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On 8/25/06, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Sorry, we did not get enough feedback to include this in 8.2. Please
> add it to pgfoundry and let's see how it goes.

Yep... it's too bad. A new feature no other database has now goes to
it's final resting place on pgfoundry.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

Jonah H. Harris wrote:
> On 8/25/06, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> Sorry, we did not get enough feedback to include this in 8.2. Please
>> add it to pgfoundry and let's see how it goes.
>
> Yep... it's too bad. A new feature no other database has now goes to
> it's final resting place on pgfoundry.
>

Jonah,

this is inaccurate, irresponsible and insulting to those of us who spend
time maintaining pgfoundry. It is not a graveyard. Plenty of stuff
outside the core gets included in packaged distributions - just see for
example what goes into the Windows distro, or the packages that CP
distributes.

The implication of your statement is that anything not accepted into the
core is automatically somehow considered unworthy. Please refer to Tom's
recent remarks about playing on extensibility as one of our strengths.

My impression (please correct me if I'm wrong) is that proper full
disjunction support would include grammar support, in which case contrib
is not where it should belong anyway. If that's so, then the next step
would be for somebody to pick up the work that Tzahi has done and take
it the rest of the way. That would be a worth goal for 8.3.

cheers

andrew

>
> this is inaccurate, irresponsible and insulting to those of us who spend
> time maintaining pgfoundry. It is not a graveyard. Plenty of stuff
> outside the core gets included in packaged distributions - just see for
> example what goes into the Windows distro, or the packages that CP
> distributes.

Jonah,

Your attitude has been lacking about this whole thing, as has a lot of
other people. PgFoundry is the official sub project site for PostgreSQL.

It is not a graveyard, projects on PgFoundry should receive full
advocacy and promotion about their abilities and their linkage PostgreSQL.

If we spent half as much time promoting and helping the various sub
project succeed as we doing whining on this list, we would be far more
dominant in the industry then we are.

I am sick of all the moaning that goes on, with this list about -- "oh
please, we need this in core". It is a crock we have a huge repository
of PostgreSQL projects that are not in core and this attitude is
detrimental and negative to all who are involved with those projects.

When full disjunctons is ready, I am sure it will be considered for
core. It currently is not and pgFoundry is the perfect place for until
until then.

We can still promote and announce we have a full disjunctions
implementation, just as we can advertise we have full text indexing.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

On 8/26/06, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> this is inaccurate, irresponsible and insulting to those of us who spend
> time maintaining pgfoundry.

Andrew,

I'm sorry if it sounded that way... it wasn't meant as such.

> It is not a graveyard. Plenty of stuff outside the core gets included in
> packaged distributions - just see for example what goes into the Windows
> distro, or the packages that CP distributes.

I'm not saying that *everything* on pgfoundry is junk... but I can
start naming dead projects if you'd like. It's like SourceForge
before SourceForge jumped the shark... now 90% of SourceForge is
either projects dead-and-gone or which hadn't even started. It's
almost not even worth the time to search SF.net anymore. I believe
that's the direction pgfoundry is headed. Not because of poor
management or administration... just that when you have a large number
of projects, the majority of which are dead or not even worth viewing,
it takes the credibility of the site down as a whole. Look at
gborg... there was some good stuff there and there still is; if you
already know about it. Both gborg and pgfoundry have projects on
there won't even work with a current version of PostgreSQL.

Outside of all us hackers... how many people actually use pgfoundry?
Does anyone have the stats? Has anyone polled users? How many of the
users are newbies and how many are already familiar with PostgreSQL?
If we don't have these basic answers, continuing to praise pgfoundry
as the home for all-things-PostgreSQL is pointless.

> The implication of your statement is that anything not accepted into the
> core is automatically somehow considered unworthy.

Not at all. I'm referring to this case in particular.

> Please refer to Tom's recent remarks about playing on extensibility
> as one of our strengths.

I never said it wasn't... extensibility is, IMHO, our *core* strength.
However, I don't think that's a good reason for pushing everything to
pgfoundry.

> My impression (please correct me if I'm wrong) is that proper full
> disjunction support would include grammar support, in which case contrib
> is not where it should belong anyway. If that's so, then the next step
> would be for somebody to pick up the work that Tzahi has done and take
> it the rest of the way. That would be a worth goal for 8.3.

You are correct, a *full* implementation would most likely include
integration into the core; grammar and all. However, being as it's an
entirely new feature in any database system ever seen, I don't think
it should be required. It's kind of funny though; it's difficult
enough to convince -hackers to adopt a feature that every other
database system in the world has, yet we're going to make it even
more difficult for an innovative feature. I can only imagine trying
to get a consensus on the grammar and implementation of a totally
nonstandard feature that only a few people really understand.

As I see it, the full disjunction code will likely end up being a low
profile project on pgfoundry because Tzahi won't have time to continue
maintaining it and not many of us have enough insight into it to do so
ourselves. As such, I don't think it's going to get enough attention
and enough of a user following to make it worth the time of one of the
core developers to pick it up.

Of course, I may always be wrong. Perhaps pgfoundry is more popular
than I've seen in past experience. Maybe one of the core developers
does want to pick up full disjunctions for 8.3.

Guess we'll just have to wait and see...

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

On 8/26/06, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> Your attitude has been lacking about this whole thing, as has a lot of
> other people. PgFoundry is the official sub project site for PostgreSQL.

That may be the case. However, all I've seen+heard is conjecture that
pgfoundry is a good thing; where's the proof? Show me and other
fellow "whiners" that a lot of people use pgfoundry and I'll gladly
shut up about it.

> It is not a graveyard, projects on PgFoundry should receive full
> advocacy and promotion about their abilities and their linkage PostgreSQL.

See previous email to Andrew regarding projects that don't work with
the latest versions of PostgreSQL. I think I've even seen a pgfoundry
project last updated for 7.x; that's certainly the case for gborg.

> If we spent half as much time promoting and helping the various sub
> project succeed as we doing whining on this list, we would be far more
> dominant in the industry then we are.

So, subprojects [pgfoundry] is the source of all industry dominance?
I wish I would've known that before :) Sorry, I was itchin' to say
it.

> I am sick of all the moaning that goes on,

So am I... in general.

> When full disjunctons is ready, I am sure it will be considered for
> core. It currently is not and pgFoundry is the perfect place for until
> until then.

As it's not a common feature, I don't think many of the hackers know
what it is or what it does. Certainly, very few have spoken on this
thread.

It's odd, only 10 people have commented on this thread; 4 of which are
core members, 2 in favor and 2 against. Yet, we're having an argument
on why this wasn't included. Unless this is the new math, 2 vs. 2
seems like a tie to me.

> We can still promote and announce we have a full disjunctions
> implementation, just as we can advertise we have full text indexing.

Wherever it ends up, I look forward to seeing the promotion and
announcements. Tzahi has put a lot of work into it over the past few
months.

I'm done on this topic but would gladly appreciate public or private
proof regarding pgfoundry's popularity.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

Jonah H. Harris wrote:
> On 8/26/06, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>> Your attitude has been lacking about this whole thing, as has a lot of
>> other people. PgFoundry is the official sub project site for PostgreSQL.
>
> That may be the case. However, all I've seen+heard is conjecture that
> pgfoundry is a good thing; where's the proof? Show me and other
> fellow "whiners" that a lot of people use pgfoundry and I'll gladly
> shut up about it.
>
>

true story.

I walked into my new boss's office the other day. He knew I was
connected with PostgreSQL (after all, that's why he gave me the job),
but we had never discussed pgfoundry - in fact he was very surprised
yesterday to hear I had anything to do with it. But that day his browser
was open on the pgfoundry home page.

So, yes, it is used, and by far more that just hard core hackers.

cheers

andrew

On 8/26/06, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> So, yes, it is used, and by far more that just hard core hackers.

OK. Kewl. I just hadn't run into many people (except hackers) that
knew about it. Thanks for sharing that.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

-----Original Message-----
From: pgsql-patches-owner(at)postgresql(dot)org on behalf of Jonah H. Harris
Sent: Sun 8/27/2006 3:24 AM
To: Joshua D. Drake
Cc: Andrew Dunstan; Bruce Momjian; Tzahi Fadida; pgsql-patches(at)postgresql(dot)org
Subject: Re: [PATCHES] Adding fulldisjunctions to the contrib

> It's odd, only 10 people have commented on this thread; 4 of which are
> core members, 2 in favor and 2 against. Yet, we're having an argument
> on why this wasn't included. Unless this is the new math, 2 vs. 2
> seems like a tie to me.

Y'know I was gonna check up on that because my recollection was that it was a 2/2 split as well, though I thought that was of people who made their view clear rather than just -core (whose opinion in this case is no more important than any of the other long time contributors imho). Don't suppose you noted the views of the other 6?

Regards, Dave.

Jonah H. Harris wrote:
> I'm not saying that *everything* on pgfoundry is junk... but I can
> start naming dead projects if you'd like.

Well, make a list and tell the admins to delete those projects.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Dave Page wrote:
>
>
> -----Original Message-----
> From: pgsql-patches-owner(at)postgresql(dot)org on behalf of Jonah H. Harris
> Sent: Sun 8/27/2006 3:24 AM
> To: Joshua D. Drake
> Cc: Andrew Dunstan; Bruce Momjian; Tzahi Fadida; pgsql-patches(at)postgresql(dot)org
> Subject: Re: [PATCHES] Adding fulldisjunctions to the contrib
>
>> It's odd, only 10 people have commented on this thread; 4 of which are
>> core members, 2 in favor and 2 against. Yet, we're having an argument
>> on why this wasn't included. Unless this is the new math, 2 vs. 2
>> seems like a tie to me.
>
> Y'know I was gonna check up on that because my recollection was that it was a 2/2 split as well, though I thought that was of people who made their view clear rather than just -core (whose opinion in this case is no more important than any of the other long time contributors imho). Don't suppose you noted the views of the other 6?

IIRC some of the rejection points, was the code:

1. Is not quite complete
2. Does not follow postgresql style guidelines

Those two items make it impossible to include Full disjunctions in core.
I believe those two points were made by Tom but I can't find his
response so if I am on crack -- I apologize in advance.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

On 8/27/06, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> Well, make a list and tell the admins to delete those projects.

Alright. When I come across one, I'll forward it on.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

On 8/27/06, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> 1. Is not quite complete

Only because it wasn't merged into the core. Which, like I said,
would be difficult to get consensus on design, grammar, and
implementation when it's a brand new and non-standard feature only a
few people understand. I honestly don't think a project like that
would've ever gotten off the ground in -hackers. Being a contrib
module makes it a bit more flexible and gives people the chance to try
it out; that way we'll see if it's worth merging into the core. Think
of it as a Phase I of Full DIsjunctions... Phase II is a bit of a
redesign and merge into 8.3.

> 2. Does not follow postgresql style guidelines

This statement was not made.

> I believe those two points were made by Tom but I can't find his
> response so if I am on crack -- I apologize in advance.

One of the points, taken a little out of context, was made by Tom.

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

> Y'know I was gonna check up on that because my recollection was that it was a 2/2 split as well, though I thought that was of people who made their view clear rather than just -core (whose opinion in this case is no more important than any of the other long time contributors imho). Don't suppose you noted the views of the other 6?

As counted, regarding inclusion in /contrib the thread sits at 5 for,
4 against, and 1 seems to lean toward making it a contrib.

Just in case my counting is wrong, this is what I've marked:

Tzahi Fadida - For
Bruce Momjian - Against
AgentM - Possibly For
Tom Lane - Against
Jonah Harris - For
David Fetter - For
Josh Drake - Against
Andrew Dunstan - Against
Josh Berkus - For
Dave Page - For

--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 2nd Floor | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/

Jonah H. Harris wrote:
>> Y'know I was gonna check up on that because my recollection was that
>> it was a 2/2 split as well, though I thought that was of people who
>> made their view clear rather than just -core (whose opinion in this
>> case is no more important than any of the other long time
>> contributors imho). Don't suppose you noted the views of the other 6?
>
> As counted, regarding inclusion in /contrib the thread sits at 5 for,
> 4 against, and 1 seems to lean toward making it a contrib.
>
> Just in case my counting is wrong, this is what I've marked:
>
> Tzahi Fadida - For
> Bruce Momjian - Against
> AgentM - Possibly For
> Tom Lane - Against
> Jonah Harris - For
> David Fetter - For
> Josh Drake - Against
> Andrew Dunstan - Against
> Josh Berkus - For
> Dave Page - For
>

Well, I don't think all your 9 qualify as long time contributors, if you
want to count numbers.

Even if there is a vote in favor, somebody has to commit it and take
responsibility for it. I at least don't have time right now.

cheers

andrew

Jonah H. Harris wrote:
> > Y'know I was gonna check up on that because my recollection was that it was a 2/2 split as well, though I thought that was of people who made their view clear rather than just -core (whose opinion in this case is no more important than any of the other long time contributors imho). Don't suppose you noted the views of the other 6?
>
> As counted, regarding inclusion in /contrib the thread sits at 5 for,
> 4 against, and 1 seems to lean toward making it a contrib.
>
> Just in case my counting is wrong, this is what I've marked:
>
> Tzahi Fadida - For
> Bruce Momjian - Against
> AgentM - Possibly For
> Tom Lane - Against
> Jonah Harris - For
> David Fetter - For
> Josh Drake - Against
> Andrew Dunstan - Against
> Josh Berkus - For
> Dave Page - For

I didn't realize the vote was even close for acceptance. I only
remember Josh saying he would use it. Saying we should have it to
remain "cutting-edge" doesn't strike me as a valid reason for inclusion,
but more of a philosophical one, which worries me. I would like it
added because people want its functionality, not because it is somehow
cool.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +