Thread: Re: [pgsql-advocacy] Increased company involvement

Re: [pgsql-advocacy] Increased company involvement

From
"Dave Held"
Date:
> -----Original Message-----
> From: Bruce Momjian [mailto:]
> Sent: Monday, May 02, 2005 12:17 PM
> To: PostgreSQL advocacy
> Cc: Dave Held; PostgreSQL-development
> Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement
>
> > [...]
> > Really?  You have a different perspective than I see.  I have
> > seen patches be accepted that had no core buy-in.  We accept
> > patches based on group feedback, not some closed approval
> > process.
>
> Let me also ask for you to provide an example of the behavior you
> describe.

Well, I think there's numerous examples where someone suggests some
feature or idea, and Tom or one or two other core developers will
say: "I don't like that idea", and then the proposer will more or
less give up on it because it is clear that it won't go anywhere.
So whether the process gets stopped at the patch submission level
or the feature proposal level isn't really relevant.  It seems pretty
clear that a handful of people decide the direction of Postgres,
and everyone else can either contribute to the features that have
been agreed to be acceptable and relevant, or they can fork their
own version.

Just watching the hackers list suggests to me that this is the norm,
rather than the exception.  I guess I'm interested to see which
patches have been accepted that the core developers opposed.  Now
don't get me wrong.  Sometimes there are good technical reasons why
feature A or B can't or shouldn't be added or even developed.  And
I don't suggest that patches lacking technical merit should not be
rejected.  But sometimes it seems that ideas with undetermined
merit get passed over because of a quick judgement based on
intuition, and only if the proposer actively fights for it for a
while does it get reconsidered.

Of course, it would be quite a bit of work for me to review the
list and compile instances where I think this has occurred, but
only because of the tedium involved to make a minor point...not
because I think I would have difficulty finding evidence.  I'm just
saying that as an outsider, if I had a lot of resources to devote
to contributing to Postgres, I would only consider working on
approved TODO items or making sure I more or less had core buy-in
before writing any code.  I don't think it would be worth my
time to work on something that non-core users/developers might
like but core hackers don't.

Like I said, that's not necessarily a bad thing.  Postgres is a
piece of software with many interacting components, and there
needs to be some coordination to make sure it evolves in a
sensible way.  But I think that implies that there must be and
is some de facto centralization of control, whether that is the
published ideology or not.

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East,  Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129

Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
>
> Well, I think there's numerous examples where someone suggests some
> feature or idea, and Tom or one or two other core developers will
> say: "I don't like that idea", and then the proposer will more or
> less give up on it because it is clear that it won't go anywhere.

Well I think that is more perception than anything. Sometimes you have
to fight for what you believe in. For example plPHP. I believe plPHP
belongs in core as do some other people. There are members of core
that are for it and against it.

Command Prompt as the submitter needs to make a valid argument to sway
core. We need to present code they would be happy with. We need to
present reasons why.

If you don't do that, then yes I can see why it would feel as if
the proposer was at a loss once someone like Tom writes his opinion.

However Tom isn't the final word, he just happens to have a lot of
weight as anyone within the project of good standing who donates as much
as he does would.

Everything within the community is pretty much done as a vote and there
are things that core really has nothing to do with (like pgFoundry).

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Re: [pgsql-advocacy] Increased company involvement

From
Bruce Momjian
Date:
Dave Held wrote:
> Just watching the hackers list suggests to me that this is the norm,
> rather than the exception.  I guess I'm interested to see which
> patches have been accepted that the core developers opposed.  Now
> don't get me wrong.  Sometimes there are good technical reasons why
> feature A or B can't or shouldn't be added or even developed.  And
> I don't suggest that patches lacking technical merit should not be
> rejected.  But sometimes it seems that ideas with undetermined
> merit get passed over because of a quick judgement based on
> intuition, and only if the proposer actively fights for it for a
> while does it get reconsidered.
>
> Of course, it would be quite a bit of work for me to review the
> list and compile instances where I think this has occurred, but
> only because of the tedium involved to make a minor point...not
> because I think I would have difficulty finding evidence.  I'm just

Well, if there was an issue and you had been around for a minimal amount
of time, I would think you could come up with at least one example.

> saying that as an outsider, if I had a lot of resources to devote
> to contributing to Postgres, I would only consider working on
> approved TODO items or making sure I more or less had core buy-in
> before writing any code.  I don't think it would be worth my
> time to work on something that non-core users/developers might
> like but core hackers don't.

Well, our developer's FAQ clearly states you should communicate your
ideas to the hackers list before starting work to be sure you have
_community_ buy-in, rather than core buy-in.

And the TODO list is not a core list, it is accumulated from community
suggestions and discussion.

> Like I said, that's not necessarily a bad thing.  Postgres is a
> piece of software with many interacting components, and there
> needs to be some coordination to make sure it evolves in a
> sensible way.  But I think that implies that there must be and
> is some de facto centralization of control, whether that is the
> published ideology or not.

I will give you the example of adding a read-only table as an example. I
am betting the idea will not be accepted because the costs outweight the
gain, but I will post my opinions on the list and others will as well
and we will come to some concensus.  If X members feel something is bad,
and 5X members think something is good, it almost always gets in --- it
doesn't matter if all the core people are in X or not.

Another example is the recent patch to check if there are orphaned file
system files.  That was submitted, Tom had questions, I posted why I
thought it was valid, and the patch is going in today.  Anyone has the
ability to argue their point and try to sway the community, and any
member has the right to request a vote on a specific issue.

Perhaps we are more a replublic because we do defer our judgement to
others who have looked into the area more thoroughly.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
                 |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: [pgsql-advocacy] Increased company involvement

From
Bruce Momjian
Date:
Joshua D. Drake wrote:
> >
> > Well, I think there's numerous examples where someone suggests some
> > feature or idea, and Tom or one or two other core developers will
> > say: "I don't like that idea", and then the proposer will more or
> > less give up on it because it is clear that it won't go anywhere.
>
> Well I think that is more perception than anything. Sometimes you have
> to fight for what you believe in. For example plPHP. I believe plPHP
> belongs in core as do some other people. There are members of core
> that are for it and against it.
>
> Command Prompt as the submitter needs to make a valid argument to sway
> core. We need to present code they would be happy with. We need to
> present reasons why.

I think the plan for plphp is to put the source in our CVS, but to
require it to be compiled as a separate 'make' step after php is fully
installed and using the new libpq.  I think we had agreement on that
solution.

> If you don't do that, then yes I can see why it would feel as if
> the proposer was at a loss once someone like Tom writes his opinion.
>
> However Tom isn't the final word, he just happens to have a lot of
> weight as anyone within the project of good standing who donates as much
> as he does would.
>
> Everything within the community is pretty much done as a vote and there
> are things that core really has nothing to do with (like pgFoundry).

Right, the point is that Tom has weight because he is Tom and people
value his opinion, not because he is core.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
                 |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Mon, 2 May 2005, Bruce Momjian wrote:

> Joshua D. Drake wrote:
>>>
>>> Well, I think there's numerous examples where someone suggests some
>>> feature or idea, and Tom or one or two other core developers will
>>> say: "I don't like that idea", and then the proposer will more or
>>> less give up on it because it is clear that it won't go anywhere.
>>
>> Well I think that is more perception than anything. Sometimes you have
>> to fight for what you believe in. For example plPHP. I believe plPHP
>> belongs in core as do some other people. There are members of core
>> that are for it and against it.
>>
>> Command Prompt as the submitter needs to make a valid argument to sway
>> core. We need to present code they would be happy with. We need to
>> present reasons why.
>
> I think the plan for plphp is to put the source in our CVS, but to
> require it to be compiled as a separate 'make' step after php is fully
> installed and using the new libpq.  I think we had agreement on that
> solution.

Last I read, both Tom and I were against it being in CVS (albeit for
different reasons) ... and there hadn't been any discussions past the end
of that thread that I've seen ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664

Re: [pgsql-advocacy] Increased company involvement

From
Bruce Momjian
Date:
Marc G. Fournier wrote:
> On Mon, 2 May 2005, Bruce Momjian wrote:
>
> > Joshua D. Drake wrote:
> >>>
> >>> Well, I think there's numerous examples where someone suggests some
> >>> feature or idea, and Tom or one or two other core developers will
> >>> say: "I don't like that idea", and then the proposer will more or
> >>> less give up on it because it is clear that it won't go anywhere.
> >>
> >> Well I think that is more perception than anything. Sometimes you have
> >> to fight for what you believe in. For example plPHP. I believe plPHP
> >> belongs in core as do some other people. There are members of core
> >> that are for it and against it.
> >>
> >> Command Prompt as the submitter needs to make a valid argument to sway
> >> core. We need to present code they would be happy with. We need to
> >> present reasons why.
> >
> > I think the plan for plphp is to put the source in our CVS, but to
> > require it to be compiled as a separate 'make' step after php is fully
> > installed and using the new libpq.  I think we had agreement on that
> > solution.
>
> Last I read, both Tom and I were against it being in CVS (albeit for
> different reasons) ... and there hadn't been any discussions past the end
> of that thread that I've seen ...

I posted this compromise and no one replied so I thought everyone was OK
with it.  It gets it into CVS, but has a separate compile stage to deal
with the recursive dependency problem.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
                 |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Mon, 2 May 2005, Bruce Momjian wrote:

> I posted this compromise and no one replied so I thought everyone was OK 
> with it.  It gets it into CVS, but has a separate compile stage to deal 
> with the recursive dependency problem.

Then what is the point of having it in CVS?  Other then to make are tar 
ball bigger?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Bruce Momjian
Date:
Marc G. Fournier wrote:
> On Mon, 2 May 2005, Bruce Momjian wrote:
> 
> > I posted this compromise and no one replied so I thought everyone was OK 
> > with it.  It gets it into CVS, but has a separate compile stage to deal 
> > with the recursive dependency problem.
> 
> Then what is the point of having it in CVS?  Other then to make are tar 
> ball bigger?

So it can be maintained with other PL languages as the internal API
changes.  This is the same reason ecpg is in our CVS because it is tied
to the grammar.

--  Bruce Momjian                        |  http://candle.pha.pa.us                |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Mon, 2 May 2005, Bruce Momjian wrote:

> Marc G. Fournier wrote:
>> On Mon, 2 May 2005, Bruce Momjian wrote:
>>
>>> I posted this compromise and no one replied so I thought everyone was OK
>>> with it.  It gets it into CVS, but has a separate compile stage to deal
>>> with the recursive dependency problem.
>>
>> Then what is the point of having it in CVS?  Other then to make are tar
>> ball bigger?
>
> So it can be maintained with other PL languages as the internal API
> changes.  This is the same reason ecpg is in our CVS because it is tied
> to the grammar.

Since when?  I thought you didn't need the PostgreSQL sources in order to 
compile pl/PHP, only the installed headers/libraries ... Joshua, has 
something changed, or did I mis-understand that requirement?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Bruce Momjian
Date:
Marc G. Fournier wrote:
> On Mon, 2 May 2005, Bruce Momjian wrote:
> 
> > Marc G. Fournier wrote:
> >> On Mon, 2 May 2005, Bruce Momjian wrote:
> >>
> >>> I posted this compromise and no one replied so I thought everyone was OK
> >>> with it.  It gets it into CVS, but has a separate compile stage to deal
> >>> with the recursive dependency problem.
> >>
> >> Then what is the point of having it in CVS?  Other then to make are tar
> >> ball bigger?
> >
> > So it can be maintained with other PL languages as the internal API
> > changes.  This is the same reason ecpg is in our CVS because it is tied
> > to the grammar.
> 
> Since when?  I thought you didn't need the PostgreSQL sources in order to 
> compile pl/PHP, only the installed headers/libraries ... Joshua, has 
> something changed, or did I mis-understand that requirement?

The issue is that we have had to wack around the existing PL languages
for almost every release to make them work with server changes, and
being outside our CVS, plPHP isn't getting that whacking.

--  Bruce Momjian                        |  http://candle.pha.pa.us                |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
> 
> 
> Since when?  I thought you didn't need the PostgreSQL sources in order 
> to compile pl/PHP, only the installed headers/libraries ... Joshua, has 
> something changed, or did I mis-understand that requirement?

Well we don't modify the backend or anything but the way plPHP is 
written it assumes it is part of the tree, which is why we have to patch.

However I think part of the argument goes to API. For example the latest 
release of plPHP will not work with 7.4.

Sincerely,

Joshua D. Drake


> 
> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> Email:            Yahoo!: yscrappy              ICQ: 7615664


-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Mon, 2 May 2005, Bruce Momjian wrote:

> Marc G. Fournier wrote:
>> On Mon, 2 May 2005, Bruce Momjian wrote:
>>
>>> Marc G. Fournier wrote:
>>>> On Mon, 2 May 2005, Bruce Momjian wrote:
>>>>
>>>>> I posted this compromise and no one replied so I thought everyone was OK
>>>>> with it.  It gets it into CVS, but has a separate compile stage to deal
>>>>> with the recursive dependency problem.
>>>>
>>>> Then what is the point of having it in CVS?  Other then to make are tar
>>>> ball bigger?
>>>
>>> So it can be maintained with other PL languages as the internal API
>>> changes.  This is the same reason ecpg is in our CVS because it is tied
>>> to the grammar.
>>
>> Since when?  I thought you didn't need the PostgreSQL sources in order to
>> compile pl/PHP, only the installed headers/libraries ... Joshua, has
>> something changed, or did I mis-understand that requirement?
>
> The issue is that we have had to wack around the existing PL languages
> for almost every release to make them work with server changes, and
> being outside our CVS, plPHP isn't getting that whacking.

And the point is, as Tom has pointed out with tsearch2, that even *in* 
CVS, it is a fair amount of work to 'whack' other ppls code ... it 
shouldn't be Tom's responsibility (which is generally what it comes down 
to) to keep someone else's code up to speed with changes in the server ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
>>
>> The issue is that we have had to wack around the existing PL languages
>> for almost every release to make them work with server changes, and
>> being outside our CVS, plPHP isn't getting that whacking.
> 
> 
> And the point is, as Tom has pointed out with tsearch2, that even *in* 
> CVS, it is a fair amount of work to 'whack' other ppls code ... it 
> shouldn't be Tom's responsibility (which is generally what it comes down 
> to) to keep someone else's code up to speed with changes in the server ...

Well we try to keep up :)


> 
> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> Email:            Yahoo!: yscrappy              ICQ: 7615664


-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


Re: [pgsql-advocacy] Increased company involvement

From
Tom Lane
Date:
"Marc G. Fournier" <> writes:
> On Mon, 2 May 2005, Bruce Momjian wrote:
>> Marc G. Fournier wrote:
>>> Then what is the point of having it in CVS?  Other then to make are tar
>>> ball bigger?
>> 
>> So it can be maintained with other PL languages as the internal API
>> changes.  This is the same reason ecpg is in our CVS because it is tied
>> to the grammar.

> Since when?  I thought you didn't need the PostgreSQL sources in order to 
> compile pl/PHP, only the installed headers/libraries ... Joshua, has 
> something changed, or did I mis-understand that requirement?

That could be said of *any* of our PLs (at least now that we install all
server-side headers by default ;-)).  I think the real reason we keep
pltcl etc in the core CVS is exactly what Bruce said: it's easier to
maintain 'em that way.  The problem is that the PLs use all sorts of
internal backend APIs that we don't want to freeze, and so they are
constantly being affected by changes in the core backend.  Just look
at the CVS logs for evidence.

Personally, I'm willing to fix the PLs whenever I make a change that
affects them, but only if they're in core CVS.  Dealing with parallel
changes in two different code repositories is too much of a pain.
So the folks maintaining non-core PLs take a big hit every release when
they have to sync with what's happened in the core backend meanwhile.
        regards, tom lane


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Mon, 2 May 2005, Joshua D. Drake wrote:

>>> 
>>> The issue is that we have had to wack around the existing PL languages
>>> for almost every release to make them work with server changes, and
>>> being outside our CVS, plPHP isn't getting that whacking.
>> 
>> 
>> And the point is, as Tom has pointed out with tsearch2, that even *in* CVS, 
>> it is a fair amount of work to 'whack' other ppls code ... it shouldn't be 
>> Tom's responsibility (which is generally what it comes down to) to keep 
>> someone else's code up to speed with changes in the server ...
>
> Well we try to keep up :)

I'm not pointing fingers at you either :)  But, you are one of how many 
that try and get 'added to core'?  How many things do we have in contrib 
that the only person that does any 'whacking' is Tom?  A couple I've seen 
patches go around for, but for a good portion of them, I imagine that they 
are 'dead except that Tom keeps fixing them' ...

Tom's focus shouldn't be making sure that everyone's third party add on 
"still works" during a release cycle, that should be the responsibility of 
the maintainers of those projects, to follow changes and make sure they 
are implemented ...

That is what pgFoundry was setup for ... to give projects the visibiilty 
they would get through the core distribution by making sure they are 
referenced in a central place, but providing the maintainers with direct 
CVS access to make changes to their code in a timely manner .. *shrug*


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
> 
> I'm not pointing fingers at you either :)  But, you are one of how many 
> that try and get 'added to core'?  How many things do we have in contrib 
> that the only person that does any 'whacking' is Tom?  A couple I've 
> seen patches go around for, but for a good portion of them, I imagine 
> that they are 'dead except that Tom keeps fixing them' ...

In contrib I would bet a lot. I have argued for the removal of TSearch 
(not TSearch2) for example. Also RServ could probably stand to be removed.

However we are not talking about contrib (or at least I am not). We were 
talking about PLs which are a little bit of a different beast.

> Tom's focus shouldn't be making sure that everyone's third party add on 
> "still works" during a release cycle, that should be the responsibility 
> of the maintainers of those projects, to follow changes and make sure 
> they are implemented ...

I would agree, I suggested test cases for contrib once. I think that 
would be very good. If the contrib fails the test case for itself say
after (this could go for pls to) Beta2 then it gets yanked.

> That is what pgFoundry was setup for ... to give projects the visibiilty 
> they would get through the core distribution by making sure they are 
> referenced in a central place, but providing the maintainers with direct 
> CVS access to make changes to their code in a timely manner .. *shrug*

It was what pgFoundry was setup for but as I have said elsewhere 
perception is everything.

If it isn't in core, it is a second class project. Regardless of how we 
all "want" to feel about it.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.




-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


Re: [pgsql-advocacy] Increased company involvement

From
Bruce Momjian
Date:
Marc G. Fournier wrote:
> On Mon, 2 May 2005, Bruce Momjian wrote:
> 
> > Marc G. Fournier wrote:
> >> On Mon, 2 May 2005, Bruce Momjian wrote:
> >>
> >>> Marc G. Fournier wrote:
> >>>> On Mon, 2 May 2005, Bruce Momjian wrote:
> >>>>
> >>>>> I posted this compromise and no one replied so I thought everyone was OK
> >>>>> with it.  It gets it into CVS, but has a separate compile stage to deal
> >>>>> with the recursive dependency problem.
> >>>>
> >>>> Then what is the point of having it in CVS?  Other then to make are tar
> >>>> ball bigger?
> >>>
> >>> So it can be maintained with other PL languages as the internal API
> >>> changes.  This is the same reason ecpg is in our CVS because it is tied
> >>> to the grammar.
> >>
> >> Since when?  I thought you didn't need the PostgreSQL sources in order to
> >> compile pl/PHP, only the installed headers/libraries ... Joshua, has
> >> something changed, or did I mis-understand that requirement?
> >
> > The issue is that we have had to wack around the existing PL languages
> > for almost every release to make them work with server changes, and
> > being outside our CVS, plPHP isn't getting that whacking.
> 
> And the point is, as Tom has pointed out with tsearch2, that even *in* 
> CVS, it is a fair amount of work to 'whack' other ppls code ... it 
> shouldn't be Tom's responsibility (which is generally what it comes down 
> to) to keep someone else's code up to speed with changes in the server ...

When a PL languages is so tied to the changing API that it will only
work for a single major release of PostgreSQL, like ecpg, it is usually
kept in our CVS.  This isn't true of odbc, jdbc, or other stuff, and not
even Slony.

--  Bruce Momjian                        |  http://candle.pha.pa.us                |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: [pgsql-advocacy] Increased company involvement

From
Bruce Momjian
Date:
Marc G. Fournier wrote:
> On Mon, 2 May 2005, Joshua D. Drake wrote:
> 
> >>> 
> >>> The issue is that we have had to wack around the existing PL languages
> >>> for almost every release to make them work with server changes, and
> >>> being outside our CVS, plPHP isn't getting that whacking.
> >> 
> >> 
> >> And the point is, as Tom has pointed out with tsearch2, that even *in* CVS, 
> >> it is a fair amount of work to 'whack' other ppls code ... it shouldn't be 
> >> Tom's responsibility (which is generally what it comes down to) to keep 
> >> someone else's code up to speed with changes in the server ...
> >
> > Well we try to keep up :)
> 
> I'm not pointing fingers at you either :)  But, you are one of how many 
> that try and get 'added to core'?  How many things do we have in contrib 
> that the only person that does any 'whacking' is Tom?  A couple I've seen 
> patches go around for, but for a good portion of them, I imagine that they 
> are 'dead except that Tom keeps fixing them' ...
> 
> Tom's focus shouldn't be making sure that everyone's third party add on 
> "still works" during a release cycle, that should be the responsibility of 
> the maintainers of those projects, to follow changes and make sure they 
> are implemented ...
> 
> That is what pgFoundry was setup for ... to give projects the visibiilty 
> they would get through the core distribution by making sure they are 
> referenced in a central place, but providing the maintainers with direct 
> CVS access to make changes to their code in a timely manner .. *shrug*
> 

The bottom line is that it is more efficient for one person to adjust
all the PL's at once rather than each PL learning about the changes and
making them.


--  Bruce Momjian                        |  http://candle.pha.pa.us                |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Mon, 2 May 2005, Joshua D. Drake wrote:

>> 
>> I'm not pointing fingers at you either :)  But, you are one of how many 
>> that try and get 'added to core'?  How many things do we have in contrib 
>> that the only person that does any 'whacking' is Tom?  A couple I've seen 
>> patches go around for, but for a good portion of them, I imagine that they 
>> are 'dead except that Tom keeps fixing them' ...
>
> In contrib I would bet a lot. I have argued for the removal of TSearch (not 
> TSearch2) for example. Also RServ could probably stand to be removed.

rserv was removed long ago ... not sure why tsearch is in there stil 
though ...

> If it isn't in core, it is a second class project. Regardless of how we 
> all "want" to feel about it.

As you've seen in the note that I sent to you ... my biggest 'beef' 
against continually adding things is the download size just keeps growing, 
and when someone already has the core installed, having to redownload it 
because they've decided to add something like pl/PHP when pl/PHP doesn't 
need anything but the headers/libraries that are already installed seems 
idiotic at best ... if some method of extending 'make dist' for the 
release cycle can be devised so that pl/PHP (and the other pl/'s would be 
nice eventually) tar *with* the core .tar.gz *and* a seperate 
plphp-<release>.tar.gz file that can be downloaded seperately, my 
arguments against will have been negated ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Bruce Momjian
Date:
Marc G. Fournier wrote:
> On Mon, 2 May 2005, Joshua D. Drake wrote:
> 
> >> 
> >> I'm not pointing fingers at you either :)  But, you are one of how many 
> >> that try and get 'added to core'?  How many things do we have in contrib 
> >> that the only person that does any 'whacking' is Tom?  A couple I've seen 
> >> patches go around for, but for a good portion of them, I imagine that they 
> >> are 'dead except that Tom keeps fixing them' ...
> >
> > In contrib I would bet a lot. I have argued for the removal of TSearch (not 
> > TSearch2) for example. Also RServ could probably stand to be removed.
> 
> rserv was removed long ago ... not sure why tsearch is in there stil 
> though ...

Why is dbmirror still there?  Can't it be moved to pgfoundry?

--  Bruce Momjian                        |  http://candle.pha.pa.us                |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Mon, 2 May 2005, Bruce Momjian wrote:

> Why is dbmirror still there?  Can't it be moved to pgfoundry?

Anyone willing to take ownership of it to setup the project itself on 
pgfoundry?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
Marc G. Fournier wrote:
> On Mon, 2 May 2005, Bruce Momjian wrote:
> 
>> Why is dbmirror still there?  Can't it be moved to pgfoundry?
> 
> 
> Anyone willing to take ownership of it to setup the project itself on 
> pgfoundry?

I thought it was still maintained?


> 
> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> Email:            Yahoo!: yscrappy              ICQ: 7615664
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend


-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


Re: [pgsql-advocacy] Increased company involvement

From
Bruce Momjian
Date:
Joshua D. Drake wrote:
> Marc G. Fournier wrote:
> > On Mon, 2 May 2005, Bruce Momjian wrote:
> > 
> >> Why is dbmirror still there?  Can't it be moved to pgfoundry?
> > 
> > 
> > Anyone willing to take ownership of it to setup the project itself on 
> > pgfoundry?
> 
> I thought it was still maintained?

Right, but it should be moved out of our CVS, I think.

--  Bruce Momjian                        |  http://candle.pha.pa.us                |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
Bruce Momjian wrote:
> Joshua D. Drake wrote:
> 
>>Marc G. Fournier wrote:
>>
>>>On Mon, 2 May 2005, Bruce Momjian wrote:
>>>
>>>
>>>>Why is dbmirror still there?  Can't it be moved to pgfoundry?
>>>
>>>
>>>Anyone willing to take ownership of it to setup the project itself on 
>>>pgfoundry?
>>
>>I thought it was still maintained?
> 
> 
> Right, but it should be moved out of our CVS, I think.

We may as well include the mSQL-interface ;) in the removal process.

Sincerely,

Joshua D. Drake




-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Mon, 2 May 2005, Bruce Momjian wrote:

> Joshua D. Drake wrote:
>> Marc G. Fournier wrote:
>>> On Mon, 2 May 2005, Bruce Momjian wrote:
>>>
>>>> Why is dbmirror still there?  Can't it be moved to pgfoundry?
>>>
>>>
>>> Anyone willing to take ownership of it to setup the project itself on
>>> pgfoundry?
>>
>> I thought it was still maintained?
>
> Right, but it should be moved out of our CVS, I think.

Agreed ... if someone can make the project, I can move the CVS files over 
... does anyone know who is currently maintaining it though?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Tom Lane
Date:
Bruce Momjian <> writes:
> Joshua D. Drake wrote:
>> Marc G. Fournier wrote:
>>> Anyone willing to take ownership of it to setup the project itself on 
>>> pgfoundry?
>> 
>> I thought it was still maintained?

> Right, but it should be moved out of our CVS, I think.

Didn't someone offer a rewritten version of dbmirror just this morning?
Maybe that person could be persuaded to run a pgfoundry project.

dbmirror is certainly a fine example of something that doesn't need to
be in the core distro as far as maintenance is concerned.  Of course,
it's also not large enough to make much of a difference in tarball size.
        regards, tom lane


Re: [pgsql-advocacy] Increased company involvement

From
"Jim C. Nasby"
Date:
On Mon, May 02, 2005 at 12:39:27PM -0500, Dave Held wrote:
> > -----Original Message-----
> > From: Bruce Momjian [mailto:]
> > Sent: Monday, May 02, 2005 12:17 PM
> > To: PostgreSQL advocacy
> > Cc: Dave Held; PostgreSQL-development
> > Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> >
> > > [...]
> > > Really?  You have a different perspective than I see.  I have
> > > seen patches be accepted that had no core buy-in.  We accept
> > > patches based on group feedback, not some closed approval
> > > process.
> >
> > Let me also ask for you to provide an example of the behavior you
> > describe.
>
> Well, I think there's numerous examples where someone suggests some
> feature or idea, and Tom or one or two other core developers will
> say: "I don't like that idea", and then the proposer will more or
> less give up on it because it is clear that it won't go anywhere.
> So whether the process gets stopped at the patch submission level
> or the feature proposal level isn't really relevant.  It seems pretty
> clear that a handful of people decide the direction of Postgres,
> and everyone else can either contribute to the features that have
> been agreed to be acceptable and relevant, or they can fork their
> own version.

I don't think it's valid to attribute this to the core team at all, but
I do understand what you're saying. Part of this is that many people
like to see data to back up a claim before adding complexity to the
database. The current read-only table discussion is a good example. How
much will it actually help to have a means to reduce the size of
HeapHeaderData? The problem is many times it's very hard to come up with
this data without actually coding something up and trying it. As Josh B.
pointed out in another post, sometimes people will suggest something on
-hackers and it just dies on the vine. This doesn't mean it wouldn't be
useful, it means no one on hackers was interested. But for every user
who's on hackers there's probably 10 than aren't and who knows how many
who might become users if some feature was added.

Personally, I think that the current process could do a better job of
gauging how much user interest there is in changes that are in the gray
area between 'wow, that's a great idea!' and 'wow, that's a horrid
idea!'. There's also the issue of people making suggestions to try and
address a larger problem. I think read-only tables is a good example;
the real issue is that in many data-mining applications the 30 byte
overhead on tuples is huge, and puts postgresql at a big disadvantage.
Read-only tables would definately be difficult to implement, but they
*could* provide a tremendous benefit to PostgreSQL performance in
certain applications. Of course, there's other changes that could also
provide benefits, such as a means to keep a table clustered (or nearly
clustered). But these things have generally been shot-down in the past,
and the data warehousing disadvantage continues.

Now I'm not suggesting that the process is seriously broken, but I do
think that the interests and experiences of the most active developers
tend to keep us away from changes that would only help a subset of users
(or potential users). I also think it would be better if that subset was
heard better. Data warehousing is the current example that comes to
mind, but I'm certain there are others.
--
Jim C. Nasby, Database Consultant               
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Re: [pgsql-advocacy] Increased company involvement

From
Andrew Dunstan
Date:

Marc G. Fournier wrote:

>>
>> The issue is that we have had to wack around the existing PL languages
>> for almost every release to make them work with server changes, and
>> being outside our CVS, plPHP isn't getting that whacking.
>
>
> And the point is, as Tom has pointed out with tsearch2, that even *in* 
> CVS, it is a fair amount of work to 'whack' other ppls code ... it 
> shouldn't be Tom's responsibility (which is generally what it comes 
> down to) to keep someone else's code up to speed with changes in the 
> server ...
>
>

Just to reiterate a previous point I have made: buildfarm does build 
(and mostly test) things in the core. I have *no* plans at all to make 
it test things not in core - currently we get code from one source and 
it would be a huge effort to change that. I *do* have plans to make it 
run the tests for each PL in core, if they are configured in the build. 
So be careful about pushing or keeping out of core things that are now 
or will soon get buildfarm testing.

The argument about tarball size I can't take seriously - the plperl 
directory for example takes 148k uncompressed in a distribution of 72 Mb.

I agree that contrib needs some considerable cleanup. For example, is 
there any good reason not to fold in the crypto stuff?

cheers

andrew




Re: [pgsql-advocacy] Increased company involvement

From
Ron Mayer
Date:
Marc G. Fournier wrote:
> 
> That is what pgFoundry was setup for ... to give projects the visibiilty 
> they would get through the core distribution by making sure they are 
> referenced in a central place, but providing the maintainers with direct 
> CVS access to make changes to their code in a timely manner .. *shrug*

As a user, I think it's not that PGFoundry projects are
second-class projects because of where they live.
I think they're second-class projects because there is
less visibility into the version computability of those
projects with postgresql compared to those in contrib.


Note that this has nothing to do with a project being "part
of core" - it's largely an documentation/organization issue
of pgFoundry itself.

I think a few changes to pgFoundry would make
packages that live there much more viable.
 * I'd like to be able to clearly see what version of a given   pgFoundry project works with which PostgreSQL major
release.  I'd like this to be consistent among all pgFoundry versions   so I can very quickly and easily find the
packageI need.
 
                  7.3.X    7.4.X   8.0.X   nightly_cvs       pgpool:       plhaskel:       [...]
  and within that table, I'd want links to source tarballs,  and possibly whatever RPMs, WindowsInstallers, etc work
andhave been tested with the given postgresql release.  It's OK for that table to be mostly empty for projects  that
havenot been tested with many versions, but if  a link is in there there, it'd be a nice way of  knowing if, for
example,plFortran works with old  versions (7.3.X) or if it's been ported to the latest  version.
 

* I'd like to see the status of pgFoundry projects on  http://www.pgbuildfarm.org/cgi-bin/show_status.pl
  Right now I have confidence in most of the contrib  modules largely because I can quickly see if they  succeed or
fail.
  I'd like any pgFoundry project that is released  into the table described above to also have regression  tests that
mustpass before they're included in that table.  Ideally, I'd like to be able to see those results for  any released
PGFoundryprojects run on pgbuildfarm as well  so the status is easily visible.
 


Even if there's no automated testing involved, I think
it'd be nice if that first table existed; and we could
just trust the developers of each project to put the
right tarballs in the right spots in the table.  I'm
wildly guessing that this more limited scope should
be a relatively easy first-step in this direction?


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
>>>
>>> I thought it was still maintained?
>>
>>
>> Right, but it should be moved out of our CVS, I think.
> 
> 
> Agreed ... if someone can make the project, I can move the CVS files 
> over ... does anyone know who is currently maintaining it though?

I can make the project but I obviously have no desire to maintain it.

Sincerely,

Joshua D. Drake

-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


Re: [pgsql-advocacy] Increased company involvement

From
Andrew Dunstan
Date:

Ron Mayer wrote:

>
>
> * I'd like to see the status of pgFoundry projects on
>   http://www.pgbuildfarm.org/cgi-bin/show_status.pl
>
>   Right now I have confidence in most of the contrib
>   modules largely because I can quickly see if they
>   succeed or fail.
>
>   I'd like any pgFoundry project that is released
>   into the table described above to also have regression
>   tests that must pass before they're included in that table.
>   Ideally, I'd like to be able to see those results for
>   any released PGFoundry projects run on pgbuildfarm as well
>   so the status is easily visible.
>

See my cross-posting where I specifically state I have no plans for 
buildfarm to test things outside core. It's doable in principle, but 
would involve huge amounts of work, for which I at least (as buildfarm's 
creator/administrator) would not have time in the foreseeable future.

cheers

andrew


Re: [pgsql-advocacy] Increased company involvement

From
"Jim C. Nasby"
Date:
On Mon, May 02, 2005 at 04:53:59PM -0400, Andrew Dunstan wrote:
> See my cross-posting where I specifically state I have no plans for 
> buildfarm to test things outside core. It's doable in principle, but 
> would involve huge amounts of work, for which I at least (as buildfarm's 
> creator/administrator) would not have time in the foreseeable future.

Would you be open to someone else adding the capability? And maybe
mention that on the buildfarm site? (And before anyone asks, no, this
doesn't interest me enough for me to do it :P)
-- 
Jim C. Nasby, Database Consultant                
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


Re: [pgsql-advocacy] Increased company involvement

From
Andrew Dunstan
Date:

Jim C. Nasby wrote:

>On Mon, May 02, 2005 at 04:53:59PM -0400, Andrew Dunstan wrote:
>  
>
>>See my cross-posting where I specifically state I have no plans for 
>>buildfarm to test things outside core. It's doable in principle, but 
>>would involve huge amounts of work, for which I at least (as buildfarm's 
>>creator/administrator) would not have time in the foreseeable future.
>>    
>>
>
>Would you be open to someone else adding the capability? And maybe
>mention that on the buildfarm site? (And before anyone asks, no, this
>doesn't interest me enough for me to do it :P)
>  
>

Of course. I won't hold my breath waiting, though :-)

cheers

andrew


Re: [pgsql-advocacy] Increased company involvement

From
Alvaro Herrera
Date:
On Mon, May 02, 2005 at 01:55:50PM -0400, Bruce Momjian wrote:
> Dave Held wrote:

> > Of course, it would be quite a bit of work for me to review the
> > list and compile instances where I think this has occurred, but
> > only because of the tedium involved to make a minor point...not
> > because I think I would have difficulty finding evidence.  I'm just
>
> Well, if there was an issue and you had been around for a minimal amount
> of time, I would think you could come up with at least one example.

I can help with that.  Somebody posted a proposal and patch to shrink
bloated btree indexes.  It's a very interesting feature but nobody
replied, so nothing happened.

The 2PC patch by Heikki Linnakangas (sp?) is also waiting and so far I
haven't seen any indication that it may be merged.

This doesn't mean I agree with Dave's argument :-)  But there are times
when no major contributor has time to "sponsor" a patch or feature, so
it goes unnoticed and unmerged.

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
Voy a acabar con todos los humanos / con los humanos yo acabaré
voy a acabar con todos / con todos los humanos acabaré (Bender)

Re: [pgsql-advocacy] Increased company involvement

From
Neil Conway
Date:
Marc G. Fournier wrote:
> Agreed ... if someone can make the project, I can move the CVS files 
> over ... does anyone know who is currently maintaining it though?

A little research would reveal:

% head contrib/dbmirror/README.dbmirror
DBMirror - PostgreSQL Database Mirroring
===================================================


DBMirror is a database mirroring system developed for the PostgreSQL
database Written and maintained by Steven Singer()

(ssinger does submit patches for it on a reasonably regular basis.)

-Neil


Re: [pgsql-advocacy] Increased company involvement

From
Pavel Stehule
Date:
>
> Another example is the recent patch to check if there are orphaned file
> system files.  That was submitted, Tom had questions, I posted why I
> thought it was valid, and the patch is going in today.  Anyone has the
> ability to argue their point and try to sway the community, and any
> member has the right to request a vote on a specific issue.
>

I know so maintainig of PostgreSQL isn't easy. And it's normal so
everybody wont to see commit of your patch. The comunication with core
developers is best, but some times I have opinion so some patches are
lost - for example my little patch SQLSTATE, .. I remeber situation one
year ago with named params of plpgsql function. Patch waited half of year.

I don't wont to be negative :-)). PostgreSQL did big progress. Really. And
last modification of plpgsql helped my in work. But its human natural. I
looking for others nows. I am expectant for 2PC, hiearch queries, and ...
PostgreSQL isn't only sw for me, it's more like idol :-)

Best Regards,
Pavel Stehule



Re: [pgsql-advocacy] Increased company involvement

From
Peter Eisentraut
Date:
Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
> I posted this compromise and no one replied so I thought everyone was OK
> with it.  It gets it into CVS, but has a separate compile stage to deal
> with the recursive dependency problem.

How will a "separate compile stage" work for actually building, say, RPM or 
Debian packages?  The only way I can see is wrapping up the PostgreSQL 
distribution tarball a second time as a "plphp" source package and build from 
there, which seems quite weird.

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


Re: [pgsql-advocacy] Increased company involvement

From
Stephen Frost
Date:
* Peter Eisentraut () wrote:
> Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
> > I posted this compromise and no one replied so I thought everyone was OK
> > with it.  It gets it into CVS, but has a separate compile stage to deal
> > with the recursive dependency problem.
>
> How will a "separate compile stage" work for actually building, say, RPM or
> Debian packages?  The only way I can see is wrapping up the PostgreSQL
> distribution tarball a second time as a "plphp" source package and build from
> there, which seems quite weird.

More than a little ugly, no thanks, please don't...

It should really be made to be buildable outside of the PostgreSQL
source tree, depending only upon the server API (which is provided in a
seperate Debian package which plphp could build-depend on).  This is
exactly how Slony will be packaged too..  From what I've gathered it
sounds like the only issue with this is that it may not get updated when
the server API changes?  Are there other issues?  Is there something it
needs that isn't or can't be provided by a seperate server API package?

(For those curious- my current plans are that slony will actually
generate a couple differnet binary debs, slon, slonik and
libpostgresql-slon or so.  libpostgresql-slon will have the .so which is
installed in the postgresql libdir, slon and slonik have their
associated programs and supporting things (.sql scripts, etc)).
Thanks,
    Stephen

Re: [pgsql-advocacy] Increased company involvement

From
Tom Lane
Date:
Peter Eisentraut <> writes:
> Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
>> I posted this compromise and no one replied so I thought everyone was OK
>> with it.  It gets it into CVS, but has a separate compile stage to deal
>> with the recursive dependency problem.

> How will a "separate compile stage" work for actually building, say, RPM or 
> Debian packages?  The only way I can see is wrapping up the PostgreSQL 
> distribution tarball a second time as a "plphp" source package and build from
> there, which seems quite weird.

I think the idea is that plphp would be in our CVS, but would not be
shipped as part of the main tarball, rather as its own separate tarball.
        regards, tom lane


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
Stephen Frost wrote:
> * Peter Eisentraut () wrote:
> 
>>Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
>>
>>>I posted this compromise and no one replied so I thought everyone was OK
>>>with it.  It gets it into CVS, but has a separate compile stage to deal
>>>with the recursive dependency problem.
>>
>>How will a "separate compile stage" work for actually building, say, RPM or 
>>Debian packages?  The only way I can see is wrapping up the PostgreSQL 
>>distribution tarball a second time as a "plphp" source package and build from 
>>there, which seems quite weird.
> 
> 
> More than a little ugly, no thanks, please don't...

Not really that ugly. It is just an extra compile step. Besides
you don't have to package it just because it is in the Tarball.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.

> 
> It should really be made to be buildable outside of the PostgreSQL
> source tree, depending only upon the server API (which is provided in a
> seperate Debian package which plphp could build-depend on).  This is
> exactly how Slony will be packaged too..  From what I've gathered it
> sounds like the only issue with this is that it may not get updated when
> the server API changes?  Are there other issues?  Is there something it
> needs that isn't or can't be provided by a seperate server API package?
> 
> (For those curious- my current plans are that slony will actually
> generate a couple differnet binary debs, slon, slonik and
> libpostgresql-slon or so.  libpostgresql-slon will have the .so which is
> installed in the postgresql libdir, slon and slonik have their
> associated programs and supporting things (.sql scripts, etc)).
> 
>     Thanks,
> 
>         Stephen



Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Tue, 3 May 2005, Tom Lane wrote:

> Peter Eisentraut <> writes:
>> Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
>>> I posted this compromise and no one replied so I thought everyone was OK
>>> with it.  It gets it into CVS, but has a separate compile stage to deal
>>> with the recursive dependency problem.
>
>> How will a "separate compile stage" work for actually building, say, RPM or
>> Debian packages?  The only way I can see is wrapping up the PostgreSQL
>> distribution tarball a second time as a "plphp" source package and build from
>> there, which seems quite weird.
>
> I think the idea is that plphp would be in our CVS, but would not be
> shipped as part of the main tarball, rather as its own separate tarball.

That is what I'm hoping for ... if it can be shipped as a seperate 
tarball, my arguments *against* including it become moot, since packagers 
(and ports) can have a nice small, quick to download package instead of 
having to re-download a >11MB file each time ...

I don't mind if its *also* ship'd in the main distribution as well, I just 
want that 'quick to download since I already have the libraries/headers 
installed' package ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Peter Eisentraut
Date:
Joshua D. Drake wrote:
> Not really that ugly. It is just an extra compile step. Besides
> you don't have to package it just because it is in the Tarball.

Since you keep raising that point: Not packaging something is not a 
valid solution to something being hard to package.

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


Re: [pgsql-advocacy] Increased company involvement

From
Thomas Hallgren
Date:
Marc G. Fournier wrote:
> On Tue, 3 May 2005, Tom Lane wrote:
>> I think the idea is that plphp would be in our CVS, but would not be
>> shipped as part of the main tarball, rather as its own separate tarball.
> 
> 
> That is what I'm hoping for ... if it can be shipped as a seperate 
> tarball, my arguments *against* including it become moot, since 
> packagers (and ports) can have a nice small, quick to download package 
> instead of having to re-download a >11MB file each time ...
> 
> I don't mind if its *also* ship'd in the main distribution as well, I 
> just want that 'quick to download since I already have the 
> libraries/headers installed' package ...
> 
Any other PL's not currently in your CVS that you might consider to 
bring in while you're at it?

Regards,
Thomas Hallgren



Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
Peter Eisentraut wrote:
> Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
> 
>>I posted this compromise and no one replied so I thought everyone was OK
>>with it.  It gets it into CVS, but has a separate compile stage to deal
>>with the recursive dependency problem.
> 
> 
> How will a "separate compile stage" work for actually building, say, RPM or 
> Debian packages?  The only way I can see is wrapping up the PostgreSQL 
> distribution tarball a second time as a "plphp" source package and build from 
> there, which seems quite weird.

Well like many rpms it will have an external dependency. You must have 
perl installed to install plPerl. The main problem here is that you 
would need a base install of php at a minimum.

The PHP installed would not need to support PostgreSQL at the time. In 
fact now that I think about it depending on how you did it, this doesn't 
effect PostgreSQl as much as it effects PHP.

You could compile and install plPHP+PostgreSQL as long as PHP was 
installed regardless of the extensions that PHP supported at the time. 
So you wouldn't need to compile PostgreSQL twice but you may need to 
compile PHP twice. Once for plPHP and then once if you wanted PostgreSQL 
support.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.



> 


-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
> 
> I don't mind if its *also* ship'd in the main distribution as well, I 
> just want that 'quick to download since I already have the 
> libraries/headers installed' package ...

We could break out all of the pls at that point? Where if you downloaded 
postgresql-opt you would get plPHP, plPerl etc...

Sincerely,

Joshua D. Drake



> 
> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> Email:            Yahoo!: yscrappy              ICQ: 7615664
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
>               http://www.postgresql.org/docs/faq


-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


Re: [pgsql-advocacy] Increased company involvement

From
Robert Treat
Date:
On Tue, 2005-05-03 at 12:40, Peter Eisentraut wrote:
> Joshua D. Drake wrote:
> > Not really that ugly. It is just an extra compile step. Besides
> > you don't have to package it just because it is in the Tarball.
> 
> Since you keep raising that point: Not packaging something is not a 
> valid solution to something being hard to package.
> 

Is telling the rpm maintainers to go fix their rpm's an option?  As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the packaging scripts which introduces dependency issues. IMHO what
is included in the postgresql cvs and what is included in the main
tarball for postgresql should not be dictated by outside packagers. 


Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL



Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Tue, 3 May 2005, Thomas Hallgren wrote:

> Marc G. Fournier wrote:
>> On Tue, 3 May 2005, Tom Lane wrote:
>>> I think the idea is that plphp would be in our CVS, but would not be
>>> shipped as part of the main tarball, rather as its own separate tarball.
>> 
>> 
>> That is what I'm hoping for ... if it can be shipped as a seperate tarball, 
>> my arguments *against* including it become moot, since packagers (and 
>> ports) can have a nice small, quick to download package instead of having 
>> to re-download a >11MB file each time ...
>> 
>> I don't mind if its *also* ship'd in the main distribution as well, I just 
>> want that 'quick to download since I already have the libraries/headers 
>> installed' package ...
>> 
> Any other PL's not currently in your CVS that you might consider to bring in 
> while you're at it?

Personally, if the above condition can be met, my objections for inclusion
of anything into core would pretty much be voided, since it eliminates the
requirement to download a 'monster tar ball' if you don't have to ...

That doesn't say anyone else would have objections, only that I wouldn't 
...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
Peter Eisentraut wrote:
> Joshua D. Drake wrote:
> 
>>Not really that ugly. It is just an extra compile step. Besides
>>you don't have to package it just because it is in the Tarball.
> 
> 
> Since you keep raising that point: Not packaging something is not a 
> valid solution to something being hard to package.

Except that I don't consider it difficult. I do it all the time, it can 
be easily scripted.

Sincerely,

Joshua D. Drake


-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
>>
>> I don't mind if its *also* ship'd in the main distribution as well, I 
>> just want that 'quick to download since I already have the 
>> libraries/headers installed' package ...
>>
> Any other PL's not currently in your CVS that you might consider to 
> bring in while you're at it?

/me heres the sound of the plJava trumpets :)

> 
> Regards,
> Thomas Hallgren
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>      joining column's datatypes do not match


-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Tue, 3 May 2005, Joshua D. Drake wrote:

>> 
>> I don't mind if its *also* ship'd in the main distribution as well, I just 
>> want that 'quick to download since I already have the libraries/headers 
>> installed' package ...
>
> We could break out all of the pls at that point? Where if you downloaded 
> postgresql-opt you would get plPHP, plPerl etc...

Optimally, you would get rid of -opt altogether, and leave it as the 
individual pl(s) ... the main purposes of the smaller tar balls is so that 
someone building a port (*BSDs) or a package (other OSs) would only need 
to download the component that applies to them, and someone installing 
from source, similar ...

Another benefit would be the ability, for instance, of there being a plPHP 
"project" on pgfoundry, where, when a release is made, the tar file is 
copied up to there (by the project maintainer, not by me) ... this would 
be good to allow sub-projects like this to be able have their own 
discussion forms, bug tracking, etc ... while the main code is still 
maintained in the main source tree ...

My primary desire is to avoid having to download several Meg of tar 
ball(s) in order to add a module to an existing server ... if that can be 
accomplished, then my main objection to adding things to the core CVS are 
eliminated ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:

> 
> My primary desire is to avoid having to download several Meg of tar 
> ball(s) in order to add a module to an existing server ... if that can 
> be accomplished, then my main objection to adding things to the core CVS 
> are eliminated ...

I guess I don't see the problem of the PostgreSQL distribution being 11 
megs, heck even 50 megs. I know that some places don't have the 
bandwidth we do but it only takes me about 90 seconds to download the 
distribution.

Sincerely,

Joshua D. Drake


-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


Re: [pgsql-advocacy] Increased company involvement

From
Andrew Dunstan
Date:

Robert Treat wrote:

>
>Is telling the rpm maintainers to go fix their rpm's an option?  As has
>been hashed out before, the only thing that makes plphp different from
>other pl's is that some of the current packagers are taking shortcuts
>with the packaging scripts which introduces dependency issues. IMHO what
>is included in the postgresql cvs and what is included in the main
>tarball for postgresql should not be dictated by outside packagers. 
>
>
>
>  
>

That wasn't my understanding of the previous discussion. Does not php 
require pg client support configured in at build time?

cheers

andrew


Re: [pgsql-advocacy] Increased company involvement

From
Tom Lane
Date:
Robert Treat <> writes:
> Is telling the rpm maintainers to go fix their rpm's an option?  As has
> been hashed out before, the only thing that makes plphp different from
> other pl's is that some of the current packagers are taking shortcuts
> with the packaging scripts which introduces dependency issues. IMHO what
> is included in the postgresql cvs and what is included in the main
> tarball for postgresql should not be dictated by outside packagers. 

"Outside packagers"?  What makes you think PG RPMs are built by outside
packagers?  The PGDG RPMs are certainly built by us, and Red Hat's PG
RPMs are built by somebody named Tom Lane, and last I heard Oliver
Elphick was handling the Debian packaging.  We have more control over
those things than you might think.  What we don't have control over is
what the PHP people choose to put in their tarball ... and that means
there's a circularity problem if we try to merge plphp.  I think you
are blaming the messengers.
        regards, tom lane


Re: [pgsql-advocacy] Increased company involvement

From
Robert Treat
Date:
On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:
> Robert Treat wrote:
> >Is telling the rpm maintainers to go fix their rpm's an option?  As has
> >been hashed out before, the only thing that makes plphp different from
> >other pl's is that some of the current packagers are taking shortcuts
> >with the packaging scripts which introduces dependency issues. IMHO what
> >is included in the postgresql cvs and what is included in the main
> >tarball for postgresql should not be dictated by outside packagers.
>
> That wasn't my understanding of the previous discussion. Does not php
> require pg client support configured in at build time?
>

If your compiling it from source, it works similarly to perl... you only need 
pg when compiling pg support into php, but you dont need tthis in for plphp. 

The problem stems from things like the php rpm spec, which has a module 
dependency on postgresql.  This would create a circular dependency if we were 
to put a dependency into the pg rpm spec for plphp.  

I think the solution to this is to create a seperate rpm spec for php-pgsql 
support, which would fall in line with how the php rpm packages are 
distributed, but I'm not an expert in rpm specs...

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Tue, 3 May 2005, Joshua D. Drake wrote:

>
>
>> 
>> My primary desire is to avoid having to download several Meg of tar ball(s) 
>> in order to add a module to an existing server ... if that can be 
>> accomplished, then my main objection to adding things to the core CVS are 
>> eliminated ...
>
> I guess I don't see the problem of the PostgreSQL distribution being 11 megs, 
> heck even 50 megs. I know that some places don't have the bandwidth we do but 
> it only takes me about 90 seconds to download the distribution.

Granted, "we in the West" are lucky ... but I know alot of ppl still on 
dialup, and I believe there are still alot of places in Europe (or is/was 
it just GB?) that pay per byte for their bandwidth ... even myself, at 
home, on a cable modem, have at times found downloads to be atrociously 
slow due to load n the network ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Tue, 3 May 2005, Marc G. Fournier wrote:

> On Tue, 3 May 2005, Joshua D. Drake wrote:
>
>> 
>> 
>>> 
>>> My primary desire is to avoid having to download several Meg of tar 
>>> ball(s) in order to add a module to an existing server ... if that can be 
>>> accomplished, then my main objection to adding things to the core CVS are 
>>> eliminated ...
>> 
>> I guess I don't see the problem of the PostgreSQL distribution being 11 
>> megs, heck even 50 megs. I know that some places don't have the bandwidth 
>> we do but it only takes me about 90 seconds to download the distribution.
>
> Granted, "we in the West" are lucky ... but I know alot of ppl still on 
> dialup, and I believe there are still alot of places in Europe (or is/was it 
> just GB?) that pay per byte for their bandwidth ... even myself, at home, on 
> a cable modem, have at times found downloads to be atrociously slow due to 
> load n the network ...

If anyone knows a *good* source for this sort of thing, please send me a 
URL, but a quick search on google finds:


"The market share for permanent connections continued to increase in 
December and now accounts for 39.4 per cent of all connections. This 
compares with a market share of 21.9 per cent a year before."
http://www.i10.org.uk/pooled/articles/BF_NEWSART/view.asp?Q=BF_NEWSART_136457

Which, to me, indicates that ~60.6% of all connections are still dial-up 
(does ISDN count as a permanent connection?) ... but, I don't know where 
they are getting their #s from, so, as I said, if someone else can point 
me to better stats, please do ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Andrew Dunstan
Date:

Robert Treat wrote:

>On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:
>  
>
>>Robert Treat wrote:
>>    
>>
>>>Is telling the rpm maintainers to go fix their rpm's an option?  As has
>>>been hashed out before, the only thing that makes plphp different from
>>>other pl's is that some of the current packagers are taking shortcuts
>>>with the packaging scripts which introduces dependency issues. IMHO what
>>>is included in the postgresql cvs and what is included in the main
>>>tarball for postgresql should not be dictated by outside packagers.
>>>      
>>>
>>That wasn't my understanding of the previous discussion. Does not php
>>require pg client support configured in at build time?
>>
>>    
>>
>
>If your compiling it from source, it works similarly to perl... you only need 
>pg when compiling pg support into php, but you dont need tthis in for plphp. 
>  
>


I suspect you are missing the point completely.

It is in fact not like building perl at all. I just downloaded 
php-4.3.11 and got this from configure --help:
 --with-pgsql[=DIR]      Include PostgreSQL support.  DIR is the PostgreSQL                         base install
directory,defaults to 
 
/usr/local/pgsql.

You will not find any such parameter for building perl.

Now it is true that you don't need this in for plphp. But if you want 
php to have pg client support you need pg built first. And no sane 
packager is going to build php twice.

I understand (correct me if I'm wrong) that php is moving to get rid of 
this compile-time dependency - but it's not gone yet, to the best of my 
knowledge.

cheers

andrew




Re: [pgsql-advocacy] Increased company involvement

From
Stephen Frost
Date:
* Robert Treat () wrote:
> If your compiling it from source, it works similarly to perl... you only need
> pg when compiling pg support into php, but you dont need tthis in for plphp.
>
> The problem stems from things like the php rpm spec, which has a module
> dependency on postgresql.  This would create a circular dependency if we were
> to put a dependency into the pg rpm spec for plphp.
>
> I think the solution to this is to create a seperate rpm spec for php-pgsql
> support, which would fall in line with how the php rpm packages are
> distributed, but I'm not an expert in rpm specs...

Just to point it out, Debian handles circular dependencies like these
without too much difficulty.  It's really only an issue when first
building the various packages, and then you just build one without all
the support initially, build the other, then rebuild the first with the
support.

So, in general, no, I don't think this should be justification for it
being part of the main source tree and as a Debian maintainer would much
prefer it be seperate and able to be compiled outside of the core
Postgres tree..
Stephen

Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Tue, 3 May 2005, Andrew Dunstan wrote:

>
>
> Robert Treat wrote:
>
>> On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:
>> 
>>> Robert Treat wrote:
>>> 
>>>> Is telling the rpm maintainers to go fix their rpm's an option?  As has
>>>> been hashed out before, the only thing that makes plphp different from
>>>> other pl's is that some of the current packagers are taking shortcuts
>>>> with the packaging scripts which introduces dependency issues. IMHO what
>>>> is included in the postgresql cvs and what is included in the main
>>>> tarball for postgresql should not be dictated by outside packagers.
>>>> 
>>> That wasn't my understanding of the previous discussion. Does not php
>>> require pg client support configured in at build time?
>>> 
>>> 
>> 
>> If your compiling it from source, it works similarly to perl... you only 
>> need pg when compiling pg support into php, but you dont need tthis in for 
>> plphp. 
>
>
> I suspect you are missing the point completely.
>
> It is in fact not like building perl at all. I just downloaded php-4.3.11 and 
> got this from configure --help:
>
> --with-pgsql[=DIR]      Include PostgreSQL support.  DIR is the PostgreSQL
>                         base install directory, defaults to 
> /usr/local/pgsql.
>
> You will not find any such parameter for building perl.
>
> Now it is true that you don't need this in for plphp. But if you want php to 
> have pg client support you need pg built first. And no sane packager is going 
> to build php twice.

Actually, if you look through FreeBSD ports, this is exactly what happens 
... when you build /usr/ports/devel/php4, it builds a "vanilla" php, no 
modules ... if you want pgsql support, you go into 
/usr/ports/databases/php4-pgsql, and build that (which has a dependency on 
lang/php4) ...

So, for plphp, a "port" would just have to install /usr/ports/lang/php4 to 
build, but would not necessarily build php4-pgsql ...

it is done this way to avoid packagers having to build a monolithich 
"contains everything" php4 ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Stephen Frost
Date:
* Tom Lane () wrote:
> Robert Treat <> writes:
> > Is telling the rpm maintainers to go fix their rpm's an option?  As has
> > been hashed out before, the only thing that makes plphp different from
> > other pl's is that some of the current packagers are taking shortcuts
> > with the packaging scripts which introduces dependency issues. IMHO what
> > is included in the postgresql cvs and what is included in the main
> > tarball for postgresql should not be dictated by outside packagers.
>
> "Outside packagers"?  What makes you think PG RPMs are built by outside
> packagers?  The PGDG RPMs are certainly built by us, and Red Hat's PG
> RPMs are built by somebody named Tom Lane, and last I heard Oliver
> Elphick was handling the Debian packaging.  We have more control over
> those things than you might think.  What we don't have control over is
> what the PHP people choose to put in their tarball ... and that means
> there's a circularity problem if we try to merge plphp.  I think you
> are blaming the messengers.

Oliver's not the only Debian person working on the PostgreSQL packages
for Debian.  Oliver certainly does a great deal of excellent work on the
core PostgreSQL packages, I don't mean to claim otherwise, but Martin
Pitt helps out a great deal with those, and various other packages are
maintained by others (such as the php4-pgsql packages, which appear to
currently be maintained by Steve Langasek, the libdbd-pg-perl packages
which appear to be maintained by Raphael Hertzog, etc).

Not arguing with you, you're right, Oliver's certainly one of the
maintainers of the Debian core PostgreSQL packages, just not the only
one.
Thanks,
    Stephen

Re: [pgsql-advocacy] Increased company involvement

From
Stephen Frost
Date:
* Marc G. Fournier () wrote:
> On Tue, 3 May 2005, Joshua D. Drake wrote:
> >We could break out all of the pls at that point? Where if you downloaded
> >postgresql-opt you would get plPHP, plPerl etc...
>
> Optimally, you would get rid of -opt altogether, and leave it as the
> individual pl(s) ... the main purposes of the smaller tar balls is so that
> someone building a port (*BSDs) or a package (other OSs) would only need
> to download the component that applies to them, and someone installing
> from source, similar ...

I tend to like this approach.  I think it'd also make it possible to
have seperate Debian packages for the different languages more easily,
which may be useful since they could more easily have different
maintainers too.  It'd also mean that you wouldn't have to have
languages installed (or at least, on the system, perhaps not
createlang'd) if you didn't want them, etc, etc.
Stephen

Re: [pgsql-advocacy] Increased company involvement

From
Andrew Dunstan
Date:

Marc G. Fournier wrote:

>> Now it is true that you don't need this in for plphp. But if you want 
>> php to have pg client support you need pg built first. And no sane 
>> packager is going to build php twice.
>
>
> Actually, if you look through FreeBSD ports, this is exactly what 
> happens ... when you build /usr/ports/devel/php4, it builds a 
> "vanilla" php, no modules ... if you want pgsql support, you go into 
> /usr/ports/databases/php4-pgsql, and build that (which has a 
> dependency on lang/php4) ...
>
> So, for plphp, a "port" would just have to install 
> /usr/ports/lang/php4 to build, but would not necessarily build 
> php4-pgsql ...
>
> it is done this way to avoid packagers having to build a monolithich 
> "contains everything" php4 ...
>

How ugly.  [remaining comments unprintable]

cheers

andrew




Re: [pgsql-advocacy] Increased company involvement

From
Stephen Frost
Date:
* Marc G. Fournier () wrote:
> On Tue, 3 May 2005, Andrew Dunstan wrote:
> >Now it is true that you don't need this in for plphp. But if you want php
> >to have pg client support you need pg built first. And no sane packager is
> >going to build php twice.
>
> Actually, if you look through FreeBSD ports, this is exactly what happens
> ... when you build /usr/ports/devel/php4, it builds a "vanilla" php, no
> modules ... if you want pgsql support, you go into
> /usr/ports/databases/php4-pgsql, and build that (which has a dependency on
> lang/php4) ...
>
> So, for plphp, a "port" would just have to install /usr/ports/lang/php4 to
> build, but would not necessarily build php4-pgsql ...
>
> it is done this way to avoid packagers having to build a monolithich
> "contains everything" php4 ...

Indeed, Debian does this for a number of packages too, and I think we
actually split out the PHP4 stuff into seperate 'source' packages in
some cases which ends up making it not actually have to be a circular
dependency (similar to Perl).
Thanks,
    Stephen

Re: [pgsql-advocacy] Increased company involvement

From
Peter Eisentraut
Date:
Stephen Frost wrote:
> Just to point it out, Debian handles circular dependencies like these
> without too much difficulty.  It's really only an issue when first
> building the various packages, and then you just build one without
> all the support initially, build the other, then rebuild the first
> with the support.

I don't really believe that.  People frequently do automated builds of 
the entire archive from scratch .  There cannot be true circular build 
dependencies.  That's the reason why the circular Qt <-> unixODBC 
dependency isn't resolved yet.

Of course, on Debian, this whole discussion is moot anyway because the 
php-pgsql client module is built from an independent source package for 
other historic reasons.

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


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Tue, 3 May 2005, Andrew Dunstan wrote:

>
>
> Marc G. Fournier wrote:
>
>>> Now it is true that you don't need this in for plphp. But if you want php 
>>> to have pg client support you need pg built first. And no sane packager is 
>>> going to build php twice.
>> 
>> 
>> Actually, if you look through FreeBSD ports, this is exactly what happens 
>> ... when you build /usr/ports/devel/php4, it builds a "vanilla" php, no 
>> modules ... if you want pgsql support, you go into 
>> /usr/ports/databases/php4-pgsql, and build that (which has a dependency on 
>> lang/php4) ...
>> 
>> So, for plphp, a "port" would just have to install /usr/ports/lang/php4 to 
>> build, but would not necessarily build php4-pgsql ...
>> 
>> it is done this way to avoid packagers having to build a monolithich 
>> "contains everything" php4 ...
>> 
>
> How ugly.  [remaining comments unprintable]

That's a matter of opinion ... in our environment, it means that clients 
can enable/disable PHP features on a per VM basis without having to build 
a new PHP binary for each ... *shrug*

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
> 
> 
> That's a matter of opinion ... in our environment, it means that clients 
> can enable/disable PHP features on a per VM basis without having to 
> build a new PHP binary for each ... *shrug*

Gentoo also does this :)

> 
> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> Email:            Yahoo!: yscrappy              ICQ: 7615664


-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


Re: [pgsql-advocacy] Increased company involvement

From
Stephen Frost
Date:
* Peter Eisentraut () wrote:
> Stephen Frost wrote:
> > Just to point it out, Debian handles circular dependencies like these
> > without too much difficulty.  It's really only an issue when first
> > building the various packages, and then you just build one without
> > all the support initially, build the other, then rebuild the first
> > with the support.
>
> I don't really believe that.  People frequently do automated builds of
> the entire archive from scratch .  There cannot be true circular build
> dependencies.  That's the reason why the circular Qt <-> unixODBC
> dependency isn't resolved yet.
>
> Of course, on Debian, this whole discussion is moot anyway because the
> php-pgsql client module is built from an independent source package for
> other historic reasons.

No, it's exactly the case, and in fact I helped John Goerzen with
exactly this issue of circular dependencies when first building the
entire archive for amd64 about a year ago.  Feel free to discuss it with
him if you don't believe me for some reason.

It may not be the case with this particular package but there are
certinaly other instances (one that's fresh to mind is the X11 packages
and groff, feel free to check it out yourself if you'd like; might be a
little better than claiming others are wrong).
Thanks,
    Stephen

Re: [pgsql-advocacy] Increased company involvement

From
Andrew Dunstan
Date:

Marc G. Fournier wrote:

>>>
>>
>> How ugly.  [remaining comments unprintable]
>
>
> That's a matter of opinion ... in our environment, it means that 
> clients can enable/disable PHP features on a per VM basis without 
> having to build a new PHP binary for each ... *shrug*
>
>

Different issue. You can do that on RH / Fedora too.

cheers

andrew


Re: [pgsql-advocacy] Increased company involvement

From
Dave Cramer
Date:

Marc G. Fournier wrote:

> On Tue, 3 May 2005, Marc G. Fournier wrote:
>
>> On Tue, 3 May 2005, Joshua D. Drake wrote:
>>
>>>
>>>
>>>>
>>>> My primary desire is to avoid having to download several Meg of tar 
>>>> ball(s) in order to add a module to an existing server ... if that 
>>>> can be accomplished, then my main objection to adding things to the 
>>>> core CVS are eliminated ...
>>>
>>>
>>> I guess I don't see the problem of the PostgreSQL distribution being 
>>> 11 megs, heck even 50 megs. I know that some places don't have the 
>>> bandwidth we do but it only takes me about 90 seconds to download 
>>> the distribution.
>>
>>
>> Granted, "we in the West" are lucky ... but I know alot of ppl still 
>> on dialup, and I believe there are still alot of places in Europe (or 
>> is/was it just GB?) that pay per byte for their bandwidth ... even 
>> myself, at home, on a cable modem, have at times found downloads to 
>> be atrociously slow due to load n the network ...
>
>
> If anyone knows a *good* source for this sort of thing, please send me 
> a URL, but a quick search on google finds:
>
>
> "The market share for permanent connections continued to increase in 
> December and now accounts for 39.4 per cent of all connections. This 
> compares with a market share of 21.9 per cent a year before."
>     http://www.i10.org.uk/pooled/articles/BF_NEWSART/view.asp?Q=BF_NEWSART_136457 
>
>
> Which, to me, indicates that ~60.6% of all connections are still 
> dial-up (does ISDN count as a permanent connection?) ... but, I don't 
> know where they are getting their #s from, so, as I said, if someone 
> else can point me to better stats, please do ...

Better stats are in the same article

Dial-up Internet connections continued to decrease, with a year on year 
fall to December 2004 of 20.1 per cent. The decrease from November to 
December 2004 was 3.1 per cent.
Although it's hard to discern what this really says ( fell 20 % or is 
20% , either way we can see a trend here )

Even if 60.6 % of all connections are dial up; what percentage of people 
downloading postgres are on dialup. The two numbers are not related.

How come we have never seen anyone complain on the lists that the 
tarball is too big ( or have we )

This issue has come up before, and I opposed it then when the interfaces 
were removed from the main tarball.
I really don't see the upside to reducing the size of the tarball at the 
expense of ease of use.  Seems to me we are
bending over backwards to make it easy for people with dial up 
connections to download our "enterprise class"
database.

Dave


>
> ----
> Marc G. Fournier           Hub.Org Networking Services 
> (http://www.hub.org)
> Email:            Yahoo!: yscrappy              ICQ: 
> 7615664
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>    (send "unregister YourEmailAddressHere" to )
>
>

-- 
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561



Re: [pgsql-advocacy] Increased company involvement

From
Robert Treat
Date:
On Tuesday 03 May 2005 13:51, Tom Lane wrote:
> Robert Treat <> writes:
> > Is telling the rpm maintainers to go fix their rpm's an option?  As has
> > been hashed out before, the only thing that makes plphp different from
> > other pl's is that some of the current packagers are taking shortcuts
> > with the packaging scripts which introduces dependency issues. IMHO what
> > is included in the postgresql cvs and what is included in the main
> > tarball for postgresql should not be dictated by outside packagers.
>
> "Outside packagers"?  What makes you think PG RPMs are built by outside
> packagers?  The PGDG RPMs are certainly built by us, and Red Hat's PG
> RPMs are built by somebody named Tom Lane, and last I heard Oliver
> Elphick was handling the Debian packaging.  We have more control over
> those things than you might think.  What we don't have control over is
> what the PHP people choose to put in their tarball ... and that means
> there's a circularity problem if we try to merge plphp.  I think you
> are blaming the messengers.
>

Don't get so defensive... I am well aware of the folks maintaining the pg 
packages... I was talking about the php packagers. 

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Tue, 3 May 2005, Dave Cramer wrote:

> How come we have never seen anyone complain on the lists that the tarball is 
> too big ( or have we )

Because ppl are downloading the "split distributions" instead of the whole 
tarball ... *every* PostgreSQL related port in FreeBSD uses the 
split-dists (only downloads the base and opt packages) ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
Marc G. Fournier wrote:
> On Tue, 3 May 2005, Dave Cramer wrote:
> 
>> How come we have never seen anyone complain on the lists that the 
>> tarball is too big ( or have we )
> 
> 
> Because ppl are downloading the "split distributions" instead of the 
> whole tarball ... *every* PostgreSQL related port in FreeBSD uses the 
> split-dists (only downloads the base and opt packages) ...

FreeBSD is a very small part of the OS planet compared to Linux and Win32.

Look at how big the Win32 installer is ;)

Sincerely,

Joshua D. Drake



-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


Re: [pgsql-advocacy] Increased company involvement

From
Dave Cramer
Date:
So nobody has complained about the tarball being too big;  yet we made 
it harder to use just in case someone might complain ?

--dc--
Marc G. Fournier wrote:

> On Tue, 3 May 2005, Dave Cramer wrote:
>
>> How come we have never seen anyone complain on the lists that the 
>> tarball is too big ( or have we )
>
>
> Because ppl are downloading the "split distributions" instead of the 
> whole tarball ... *every* PostgreSQL related port in FreeBSD uses the 
> split-dists (only downloads the base and opt packages) ...
>
> ----
> Marc G. Fournier           Hub.Org Networking Services 
> (http://www.hub.org)
> Email:            Yahoo!: yscrappy              ICQ: 
> 7615664
>
>

-- 
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561



Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Tue, 3 May 2005, Joshua D. Drake wrote:

> Marc G. Fournier wrote:
>> On Tue, 3 May 2005, Dave Cramer wrote:
>> 
>>> How come we have never seen anyone complain on the lists that the tarball 
>>> is too big ( or have we )
>> 
>> 
>> Because ppl are downloading the "split distributions" instead of the whole 
>> tarball ... *every* PostgreSQL related port in FreeBSD uses the split-dists 
>> (only downloads the base and opt packages) ...
>
> FreeBSD is a very small part of the OS planet compared to Linux and Win32.
>
> Look at how big the Win32 installer is ;)

Agreed, but that is a binary distribution ... also, and this is based only 
one the impression I've gotten from the list(s), and not on actually 
trying it, doesn't it include 'multiple smaller packages' that you can 
either install all of, or pieces of?

As to FreeBSD vs Linux ... I don't have enough experience with Linux and 
how the packages work over there, but I don't believe that if someone were 
to download/package a plphp SRPM (or package) that they would include the 
whole 11MB tar file, would they?  Or would they just package up that 
component which is applicable and have dependencies on other packages?

Hell, let's go at it from the other side of the coin ... you talk about 
how fast your connection is to download it ... but it has to come from 
somewhere ... which is more 'mirror friendly'?  Making everyone download 
11MB at a time for a, what would plPHP be, 100k directory structure, or 
give them a 50k compressed tar file to download to get the component they 
require?  I'm basing that estimate on how big the existing pls are in the 
source tree, so I may be high/low on the real size of plphp ...

The point is that *if* something can be build using existing 
libraries/headers on the machine, without requiring the full source tree 
to build it, then providing the option to the downloader/packager/port to 
get the smaller piece is "A Good Thing" ... the only person that has made 
a compelling argument why PLs should be in the core CVS *at this time* is 
Tom (as regards the API changing, and its generally easier for him to 
modify the PLs then having the "maintainers" learn the changes), and that 
makes sense ... but as far as "packaging" on our end is concerned, if we 
can split off 'stand alone distributions', then that is what we should be 
looking at doing ...

Hell ... my "dream" is to see a libpq-<version>.tar.gz distribution so 
that I don't have to download the full server source code each time I want 
to install onto a client machine ... and one of these days I'll figure out 
how to do it ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Tue, 3 May 2005, Dave Cramer wrote:

> So nobody has complained about the tarball being too big;  yet we made it 
> harder to use just in case someone might complain ?

Made what harder to use?  You don't like the split, download the full tar 
ball ... both options are available to you ... myself, I find my time 
better spent working on the end application, not download a bunch of docs 
and stuff that I don't need to install ... each to their own ... but, 
again, the options are avaialble to you ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Mon, 2 May 2005, Alvaro Herrera wrote:

> The 2PC patch by Heikki Linnakangas (sp?) is also waiting and so far I
> haven't seen any indication that it may be merged.

Actually, its one of the features we have planned to have merged for 8.1
... :)

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664

Re: [pgsql-advocacy] Increased company involvement

From
Robert Treat
Date:
On Monday 02 May 2005 15:12, Tom Lane wrote:
> "Marc G. Fournier" <> writes:
> > On Mon, 2 May 2005, Bruce Momjian wrote:
> >> Marc G. Fournier wrote:
> >>> Then what is the point of having it in CVS?  Other then to make are tar
> >>> ball bigger?
> >>
> >> So it can be maintained with other PL languages as the internal API
> >> changes.  This is the same reason ecpg is in our CVS because it is tied
> >> to the grammar.
> >
> > Since when?  I thought you didn't need the PostgreSQL sources in order to
> > compile pl/PHP, only the installed headers/libraries ... Joshua, has
> > something changed, or did I mis-understand that requirement?
>
> That could be said of *any* of our PLs (at least now that we install all
> server-side headers by default ;-)).  I think the real reason we keep
> pltcl etc in the core CVS is exactly what Bruce said: it's easier to
> maintain 'em that way.  The problem is that the PLs use all sorts of
> internal backend APIs that we don't want to freeze, and so they are
> constantly being affected by changes in the core backend.  Just look
> at the CVS logs for evidence.
>
> Personally, I'm willing to fix the PLs whenever I make a change that
> affects them, but only if they're in core CVS.  Dealing with parallel
> changes in two different code repositories is too much of a pain.
> So the folks maintaining non-core PLs take a big hit every release when
> they have to sync with what's happened in the core backend meanwhile.
>

Somewhere I think OS independence is a factor here.  Things in the core distro 
can generally be figured to work on multiple platforms, especially if the are 
getting put through some compiling via the buildfarm.  Code on pgfoundry is 
probably less likely to work on multiple OS's simply because they may not 
have the developer eyeballs to spare for extra platforms.  On some projects 
like slony this is probably fine, as you can wait for intrest to spring up 
before needing to do some work, however other things like odbc or maybe 
libpqxx are things that we really do want to be able to work on all our 
supported platforms, and having them outside core hurts thier chances. 

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


Re: [pgsql-advocacy] Increased company involvement

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
> > I posted this compromise and no one replied so I thought everyone was OK
> > with it.  It gets it into CVS, but has a separate compile stage to deal
> > with the recursive dependency problem.
> 
> How will a "separate compile stage" work for actually building, say, RPM or 
> Debian packages?  The only way I can see is wrapping up the PostgreSQL 
> distribution tarball a second time as a "plphp" source package and build from 
> there, which seems quite weird.

My idea is that the second stage would just have them go to src/pl/plphp
and type 'gmake install'.

--  Bruce Momjian                        |  http://candle.pha.pa.us                |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: [pgsql-advocacy] Increased company involvement

From
Tom Lane
Date:
Bruce Momjian <> writes:
> My idea is that the second stage would just have them go to src/pl/plphp
> and type 'gmake install'.

Absolutely not.  It has to work as an independent package, not as
something that expects to build inside an already-configured Postgres
source tree.  That means its own configure etc.

Basically, we can keep the files in our CVS for ease of maintenance,
but that is not going to show up at all in terms of what is shipped
in the two tarballs --- they will be independent products.
        regards, tom lane


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
Tom Lane wrote:
> Bruce Momjian <> writes:
> 
>>My idea is that the second stage would just have them go to src/pl/plphp
>>and type 'gmake install'.
> 
> 
> Absolutely not.  It has to work as an independent package, not as
> something that expects to build inside an already-configured Postgres
> source tree.  That means its own configure etc.

Wait I am confused. Right now plPHP is setup to be a part of the source 
tree. It uses ./configure --with-php etc...

So where are we going?

Sincerely,

Joshua D. Drake


> 
> Basically, we can keep the files in our CVS for ease of maintenance,
> but that is not going to show up at all in terms of what is shipped
> in the two tarballs --- they will be independent products.
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to  so that your
>       message can get through to the mailing list cleanly


-- 
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Wed, 4 May 2005, Joshua D. Drake wrote:

> Tom Lane wrote:
>> Bruce Momjian <> writes:
>> 
>>> My idea is that the second stage would just have them go to src/pl/plphp
>>> and type 'gmake install'.
>> 
>> 
>> Absolutely not.  It has to work as an independent package, not as
>> something that expects to build inside an already-configured Postgres
>> source tree.  That means its own configure etc.
>
> Wait I am confused. Right now plPHP is setup to be a part of the source tree. 
> It uses ./configure --with-php etc...
>
> So where are we going?

plphp.tar.gz being seperately buildable from the core distribution, 
without the core distribution source files ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Tom Lane
Date:
"Marc G. Fournier" <> writes:
> On Wed, 4 May 2005, Joshua D. Drake wrote:
>> So where are we going?

> plphp.tar.gz being seperately buildable from the core distribution, 
> without the core distribution source files ...

That is, plphp should build against an installed set of postgres
headers, not within a postgres source tree.  This is the only workable
thing from the standpoint of downstream packagers.
        regards, tom lane


Re: [pgsql-advocacy] Increased company involvement

From
"Joshua D. Drake"
Date:
Tom Lane wrote:
> "Marc G. Fournier" <> writes:
> 
>>On Wed, 4 May 2005, Joshua D. Drake wrote:
>>
>>>So where are we going?
> 
> 
>>plphp.tar.gz being seperately buildable from the core distribution, 
>>without the core distribution source files ...
> 
> 
> That is, plphp should build against an installed set of postgres
> headers, not within a postgres source tree.  This is the only workable
> thing from the standpoint of downstream packagers.

O.k. let me run this through the developers. I can't imagine that it 
will be that difficult.

Sincerely,

Joshua D. Drake


> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match



Re: [pgsql-advocacy] Increased company involvement

From
Tom Lane
Date:
"Joshua D. Drake" <> writes:
> Kind of offtopic but at that point should we also include plJava?

Not decided, but it's surely on the radar screen for this discussion.
Joe Conway's PL/R is in the back of my mind as well --- it likely has
a smaller userbase than the first two, but from a maintenance standpoint
it probably belongs on the same level.

> Should we put plPHP in contrib/plphp? With its own build options?

Not under contrib either: it's got to be a separate source tree.
I grow a bit weary and am not seeing exactly how this maps to a CVS
setup... do we need more than one CVS module?
        regards, tom lane


Re: [pgsql-advocacy] Increased company involvement

From
Josh Berkus
Date:
Tom,

> Not decided, but it's surely on the radar screen for this discussion.
> Joe Conway's PL/R is in the back of my mind as well --- it likely has
> a smaller userbase than the first two, but from a maintenance standpoint
> it probably belongs on the same level.

Yeah, except PL/R has wierd build requirements (FORTRAN) and different 
licensing (R is GPL).  :-(

-- 
Josh Berkus
Aglio Database Solutions
San Francisco


Re: [pgsql-advocacy] Increased company involvement

From
Tom Lane
Date:
Josh Berkus <> writes:
>> Joe Conway's PL/R is in the back of my mind as well

> Yeah, except PL/R has wierd build requirements (FORTRAN) and different 
> licensing (R is GPL).  :-(

[ shrug... ]  All of the PLs except plpgsql require an outside language
interpreter that has its own license and possibly problematic build
requirements.  We are not proposing including any of those things into
our own distribution, only trying to figure out the best way to build PL
modules that depend on both Postgres and these other projects.

If we can see the right way to do this, I'd be in favor of pulling all
of pltcl, plperl, and plpython out of the core distro.  They are all
sources of undesirable build dependencies.
        regards, tom lane


Re: [pgsql-advocacy] Increased company involvement

From
Joe Conway
Date:
Josh Berkus wrote:
> 
>>Not decided, but it's surely on the radar screen for this discussion.
>>Joe Conway's PL/R is in the back of my mind as well --- it likely has
>>a smaller userbase than the first two, but from a maintenance standpoint
>>it probably belongs on the same level.
> 
> Yeah, except PL/R has wierd build requirements (FORTRAN) and different 
> licensing (R is GPL).  :-(

R requires FORTRAN to build, but PL/R doesn't. PL/R just needs an 
installed copy of libR.so (or equiv). Also, PL/R can build using pgxs 
now, so it doesn't even need a Postgres source tree.

I've considered relicensing PL/R with a BSD license, but I haven't been 
able to decide whether I really can do that given libR's GPL status, and 
I'm afraid it might tick off the R core developers if I do.

Joe

(quiet lately, but still lurking...)


Re: [pgsql-advocacy] Increased company involvement

From
Dave Cramer
Date:
pl-j and pl/java are working together to create a shared interface so that <br /> they can co-exist. This is the part
thatwe wish to have added to the main source<br /> tree. It will just be the C portion of the code that does rely on
thebackend.<br /><br /> Dave<br /><br /> Tom Lane wrote: <blockquote cite=""
type="cite"><prewrap="">"Joshua D. Drake" <a class="moz-txt-link-rfc2396E"
href="mailto:"><></a>writes: </pre><blockquote type="cite"><pre
wrap="">Kindof offtopic but at that point should we also include plJava?   </pre></blockquote><pre wrap="">
 
Not decided, but it's surely on the radar screen for this discussion.
Joe Conway's PL/R is in the back of my mind as well --- it likely has
a smaller userbase than the first two, but from a maintenance standpoint
it probably belongs on the same level.
 </pre><blockquote type="cite"><pre wrap="">Should we put plPHP in contrib/plphp? With its own build options?
</pre></blockquote><prewrap="">
 
Not under contrib either: it's got to be a separate source tree.
I grow a bit weary and am not seeing exactly how this maps to a CVS
setup... do we need more than one CVS module?
        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command   (send "unregister YourEmailAddressHere" to <a
class="moz-txt-link-abbreviated"href="mailto:"></a>)
 

 </pre></blockquote><br /><pre class="moz-signature" cols="72">-- 
Dave Cramer
<a class="moz-txt-link-freetext" href="http://www.postgresintl.com">http://www.postgresintl.com</a>
519 939 0336
ICQ#14675561
</pre>

Re: [pgsql-advocacy] Increased company involvement

From
Tom Lane
Date:
Joe Conway <> writes:
> I've considered relicensing PL/R with a BSD license, but I haven't been 
> able to decide whether I really can do that given libR's GPL status, and 
> I'm afraid it might tick off the R core developers if I do.

The direction I see this going in wouldn't require relicensing.  I don't
see any problem with having both BSD and GPL code in our CVS.  What we
want is to try to keep them separate in what we ship: the core tarball
should include only BSD code, but other tarballs could be GPL or LGPL
or whatever.

Given that PL/R depends on linking to a GPL'd R library, it'd be pretty
pointless to insist on PL/R being BSD anyway --- to use it, you'd still
have to obey the restrictions of the GPL.
        regards, tom lane


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Thu, 5 May 2005, Dave Cramer wrote:

> pl-j and pl/java are working together to create a shared interface so 
> that they can co-exist. This is the part that we wish to have added to 
> the main source tree. It will just be the C portion of the code that 
> does rely on the backend.

Note that what Tom is proposing is actually yanking *all* PLs from the 
core source tree, but having them all within the core CVS ... I believe 
his "motivation" is that he only has one CVSROOT to set to get at all the 
files, but that they are seperate from the core distribution itself ...

Basically, each has to be buildable/distributable standalone, but easily 
accessible for making changes if/when APIs change ...


Tom, am I understanding correctly?


 > 
> Dave >
> Tom Lane wrote:
>
>> "Joshua D. Drake" <> writes:
>> 
>>> Kind of offtopic but at that point should we also include plJava?
>>> 
>> 
>> Not decided, but it's surely on the radar screen for this discussion.
>> Joe Conway's PL/R is in the back of my mind as well --- it likely has
>> a smaller userbase than the first two, but from a maintenance standpoint
>> it probably belongs on the same level.
>> 
>> 
>>> Should we put plPHP in contrib/plphp? With its own build options?
>>> 
>> 
>> Not under contrib either: it's got to be a separate source tree.
>> I grow a bit weary and am not seeing exactly how this maps to a CVS
>> setup... do we need more than one CVS module?
>> 
>>             regards, tom lane
>> 
>> ---------------------------(end of broadcast)---------------------------
>> TIP 2: you can get off all lists at once with the unregister command
>>    (send "unregister YourEmailAddressHere" to )
>> 
>> 
>> 
>
> -- 
> Dave Cramer
> http://www.postgresintl.com
> 519 939 0336
> ICQ#14675561
>
>

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Tom Lane
Date:
"Marc G. Fournier" <> writes:
> Note that what Tom is proposing is actually yanking *all* PLs from the 
> core source tree, but having them all within the core CVS ... I believe 
> his "motivation" is that he only has one CVSROOT to set to get at all the 
> files, but that they are seperate from the core distribution itself ...

plpgsql should probably stay where it is, since it has no special
outside dependencies, but the other three could be separated out.

> Basically, each has to be buildable/distributable standalone, but easily 
> accessible for making changes if/when APIs change ...

I want them all in the same CVS basically to avoid any version skew
issues.  They should always have the same branches and the same tags
as the core, for instance; and it seems hard to keep separate
repositories in sync that closely.

But packaging them as separately buildable tarballs that depend only
on the installed core fileset (headers + pgxs) seems a fine idea.
        regards, tom lane


Re: [pgsql-advocacy] Increased company involvement

From
Dave Cramer
Date:
What we are proposing is just including the C code which will have no 
external
dependancies.

We understand that building the java pl's requires many tools which are 
not normally
available to people building the source.


Dave

Tom Lane wrote:

>"Marc G. Fournier" <> writes:
>  
>
>>Note that what Tom is proposing is actually yanking *all* PLs from the 
>>core source tree, but having them all within the core CVS ... I believe 
>>his "motivation" is that he only has one CVSROOT to set to get at all the 
>>files, but that they are seperate from the core distribution itself ...
>>    
>>
>
>plpgsql should probably stay where it is, since it has no special
>outside dependencies, but the other three could be separated out.
>
>  
>
>>Basically, each has to be buildable/distributable standalone, but easily 
>>accessible for making changes if/when APIs change ...
>>    
>>
>
>I want them all in the same CVS basically to avoid any version skew
>issues.  They should always have the same branches and the same tags
>as the core, for instance; and it seems hard to keep separate
>repositories in sync that closely.
>
>But packaging them as separately buildable tarballs that depend only
>on the installed core fileset (headers + pgxs) seems a fine idea.
>
>            regards, tom lane
>
>
>  
>

-- 
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561



Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Thu, 5 May 2005, Tom Lane wrote:

> "Marc G. Fournier" <> writes:
>> Note that what Tom is proposing is actually yanking *all* PLs from the
>> core source tree, but having them all within the core CVS ... I believe
>> his "motivation" is that he only has one CVSROOT to set to get at all the
>> files, but that they are seperate from the core distribution itself ...
>
> plpgsql should probably stay where it is, since it has no special
> outside dependencies, but the other three could be separated out.
>
>> Basically, each has to be buildable/distributable standalone, but easily
>> accessible for making changes if/when APIs change ...
>
> I want them all in the same CVS basically to avoid any version skew
> issues.  They should always have the same branches and the same tags
> as the core, for instance; and it seems hard to keep separate
> repositories in sync that closely.
>
> But packaging them as separately buildable tarballs that depend only
> on the installed core fileset (headers + pgxs) seems a fine idea.

Based on that criteria, I wouldn't be adverse to having a "static copy" of 
stuff like JDBC/ODBC in the core CVS ... not development copies, but 
something that Dave could submit a patch to close to a release so that 
when packaging/tagging is done, a jdbc.tar.gz package (or odbc.tar.gz 
package) could also be included "as part of the core distribution" ... 
same with the various libs ...

development for each would still be on pgfoundry/gborg ...

it would just mean that when someone went to:
    /pub/source/v8.1.0

they would find a libpqxx.tar.gz, jdbc.tar.gz, odbc.tar.gz, etc file ...

not sure if that would create more headaches then its worth though, but 
its a thought ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Josh Berkus
Date:
Joe,

> I've considered relicensing PL/R with a BSD license, but I haven't been
> able to decide whether I really can do that given libR's GPL status, and
> I'm afraid it might tick off the R core developers if I do.

Seems like you could ask them.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco


Re: [pgsql-advocacy] Increased company involvement

From
Peter Eisentraut
Date:
Tom Lane wrote:
> I want them all in the same CVS basically to avoid any version skew
> issues.  They should always have the same branches and the same tags
> as the core, for instance; and it seems hard to keep separate
> repositories in sync that closely.

Can you have the same tags across different modules in the same CVS 
server?  If so, that would work.

> But packaging them as separately buildable tarballs that depend only
> on the installed core fileset (headers + pgxs) seems a fine idea.

If, as it currently appears, we'll end up moving in all of plphp, 
pljava, plr, then we might as well be consistent and offer all 
procedural languages, with the possible exception of plpgsql, 
exclusively as a separate tarball, to be released exactly when a server 
release is done.

Of course, there are a bunch of build infrastructure issues to be worked 
out, but let's settle on the tree structure first and then think about 
the build issues.  (But don't just move stuff and *then* think about 
the build issues.)

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


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Thu, 5 May 2005, Peter Eisentraut wrote:

> Can you have the same tags across different modules in the same CVS 
> server?  If so, that would work.

I believe that I can made a 'meta module' that, if I checked it out, would 
include all sub-modules, and that I can tag/branch appropriately ... if 
not, its just a matter of looping through each at the same time, a little 
more work, but not much more ...

> If, as it currently appears, we'll end up moving in all of plphp, 
> pljava, plr, then we might as well be consistent and offer all 
> procedural languages, with the possible exception of plpgsql, 
> exclusively as a separate tarball, to be released exactly when a server 
> release is done.

I believe that that is what Tom is proposing, and that I'm 
enthusiastically endorsing ..

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Josh Berkus
Date:
Tom,

> But packaging them as separately buildable tarballs that depend only
> on the installed core fileset (headers + pgxs) seems a fine idea.

I really can't see doing this without a better (i.e. CPAN / emerge / ports - 
like ) build system.    Mind you, I'd really like such a build system, but if 
we require users to manually download several separate tarballs and untar 
them in exactly the right spot in the source tree, we're adding a bunch of 
extra effort for both users and packagers.

Improving the download/build/install process needs to be part of "pushing out" 
any core stuff.   Of course, if we can make improvements, that could also 
lead to having an "all drivers" tarball that would build easily, and 
packaging other add-ons for easy build, which would be cool.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco


Re: [pgsql-advocacy] Increased company involvement

From
Tom Lane
Date:
"Marc G. Fournier" <> writes:
> On Thu, 5 May 2005, Peter Eisentraut wrote:
>> Can you have the same tags across different modules in the same CVS 
>> server?  If so, that would work.

> I believe that I can made a 'meta module' that, if I checked it out, would 
> include all sub-modules, and that I can tag/branch appropriately ... if 
> not, its just a matter of looping through each at the same time, a little 
> more work, but not much more ...

Probably not worth the trouble compared to just putting them as
separate top-level directories in the checkout tree.  Our last
experiment with multiple modules didn't go very well.

One thought here --- would we also separate out the documentation for
them?  That would have some negative effects (make the documentation
less seamless) but I'm not sure we'd have any choice.
        regards, tom lane


Re: [pgsql-advocacy] Increased company involvement

From
Andrew Dunstan
Date:

Peter Eisentraut wrote:

>Tom Lane wrote:
>  
>
>>I want them all in the same CVS basically to avoid any version skew
>>issues.  They should always have the same branches and the same tags
>>as the core, for instance; and it seems hard to keep separate
>>repositories in sync that closely.
>>    
>>
>
>Can you have the same tags across different modules in the same CVS 
>server?  If so, that would work.
>  
>

I'm not sure you can tag more than one module at a time. But why would a 
different module be needed? We split the current single module into 
different tarballs, don't we?

>  
>
>>But packaging them as separately buildable tarballs that depend only
>>on the installed core fileset (headers + pgxs) seems a fine idea.
>>    
>>
>
>If, as it currently appears, we'll end up moving in all of plphp, 
>pljava, plr, then we might as well be consistent and offer all 
>procedural languages, with the possible exception of plpgsql, 
>exclusively as a separate tarball, to be released exactly when a server 
>release is done.
>  
>

One per language, or just an "extra language" pack?

>Of course, there are a bunch of build infrastructure issues to be worked 
>out, but let's settle on the tree structure first and then think about 
>the build issues.  (But don't just move stuff and *then* think about 
>the build issues.)
>
>  
>

I agree.

I hope we can also still configure/build/test as now - if not you will 
make my life harder, and it will take lots longer to implement my plan 
to test PLs in buildfarm.

cheers

andrew


Re: [pgsql-advocacy] Increased company involvement

From
Tom Lane
Date:
Josh Berkus <> writes:
>> But packaging them as separately buildable tarballs that depend only
>> on the installed core fileset (headers + pgxs) seems a fine idea.

> I really can't see doing this without a better (i.e. CPAN / emerge / ports - 
> like ) build system.    Mind you, I'd really like such a build system, but if
> we require users to manually download several separate tarballs and untar 
> them in exactly the right spot in the source tree, we're adding a bunch of 
> extra effort for both users and packagers.

Uh, that's not exactly what is being proposed.  It would be a separate
tarball that you could untar wherever you felt like, because it would
not depend on the core source tree at all --- only on the files
installed by a previous build of the core.

I think Marc just suggested having all the PLs in one such tarball,
rather than one for each which is what I was envisioning.  That would
probably fix the "too many things to download" issue.  Offhand it
doesn't seem like it makes the what-order-do-I-build-my-RPMs in problem
any worse.  It would complicate the license issue though.  For ease of
labeling you really want all the code in a given tarball to have the
same license, and we couldn't expect to have that for all the PLs.
        regards, tom lane


Re: [pgsql-advocacy] Increased company involvement

From
Joe Conway
Date:
Josh Berkus wrote:
> 
> Seems like you could ask them.
> 

Done that. They give about the same reaction as we do when someone 
suggests Postgres should be GPL'd

Joe


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Thu, 5 May 2005, Tom Lane wrote:

> "Marc G. Fournier" <> writes:
>> On Thu, 5 May 2005, Peter Eisentraut wrote:
>>> Can you have the same tags across different modules in the same CVS
>>> server?  If so, that would work.
>
>> I believe that I can made a 'meta module' that, if I checked it out, would
>> include all sub-modules, and that I can tag/branch appropriately ... if
>> not, its just a matter of looping through each at the same time, a little
>> more work, but not much more ...
>
> Probably not worth the trouble compared to just putting them as
> separate top-level directories in the checkout tree.  Our last
> experiment with multiple modules didn't go very well.

Actually, this is what I was planning ... each 'separate top-level 
directories' is classified as a seperate module ... it is those 'separate 
top-level directories' that I believe I can setup a "virtual meta module" 
for for purposes of tagging/branching ... it wouldn't be something anyone 
but I would ever look at ...

> One thought here --- would we also separate out the documentation for 
> them?  That would have some negative effects (make the documentation 
> less seamless) but I'm not sure we'd have any choice.

I'd *love* to see a centralized docs module created ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Thu, 5 May 2005, Tom Lane wrote:

> Josh Berkus <> writes:
>>> But packaging them as separately buildable tarballs that depend only
>>> on the installed core fileset (headers + pgxs) seems a fine idea.
>
>> I really can't see doing this without a better (i.e. CPAN / emerge / ports -
>> like ) build system.    Mind you, I'd really like such a build system, but if
>> we require users to manually download several separate tarballs and untar
>> them in exactly the right spot in the source tree, we're adding a bunch of
>> extra effort for both users and packagers.
>
> Uh, that's not exactly what is being proposed.  It would be a separate
> tarball that you could untar wherever you felt like, because it would
> not depend on the core source tree at all --- only on the files
> installed by a previous build of the core.
>
> I think Marc just suggested having all the PLs in one such tarball,
> rather than one for each which is what I was envisioning.

Nope, I should have shut up about this, actually ... all I was proposing 
was an easy way for me (and nobody else) to do simultaneious tagging and 
branching without having to check out multiple modules individually ... as 
I said, I should have shut up about it, since its not something anyone 
else would care about :)

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Thu, 5 May 2005, Andrew Dunstan wrote:

>
>
> Peter Eisentraut wrote:
>
>> Tom Lane wrote:
>> 
>>> I want them all in the same CVS basically to avoid any version skew
>>> issues.  They should always have the same branches and the same tags
>>> as the core, for instance; and it seems hard to keep separate
>>> repositories in sync that closely.
>>> 
>> 
>> Can you have the same tags across different modules in the same CVS server? 
>> If so, that would work.
>> 
>
> I'm not sure you can tag more than one module at a time. But why would a 
> different module be needed? We split the current single module into different 
> tarballs, don't we?

Ya, but Tom is talking about totally self-contained, self-configured, 
self-building "don't need the core source distribution in the least bit" 
distributions ...

CVSROOT is all in the same place, and the source packages would all be 
within the same directory as the core postgresql distribution ("one 
central ftp directory"), but all that would be required to build one would 
be that the libraries/headers are already installed on teh server in 
question ...

>> If, as it currently appears, we'll end up moving in all of plphp, pljava, 
>> plr, then we might as well be consistent and offer all procedural 
>> languages, with the possible exception of plpgsql, exclusively as a 
>> separate tarball, to be released exactly when a server release is done.
>> 
>
> One per language, or just an "extra language" pack?

one per pl ... so if we were to include, say, pl/j and pl/java, in the 
core CVS repository, they would be seperate modules, and seperate 
distributions ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Josh Berkus
Date:
Tom,

> Uh, that's not exactly what is being proposed.  It would be a separate
> tarball that you could untar wherever you felt like, because it would
> not depend on the core source tree at all --- only on the files
> installed by a previous build of the core.

Still sounds good.  Do you think that this system could be extended to other 
add-ons in the future which are currently more complex builds?  And allow us 
to out some of the wierder things in /contrib?

-- 
Josh Berkus
Aglio Database Solutions
San Francisco


Re: [pgsql-advocacy] Increased company involvement

From
Tom Lane
Date:
Josh Berkus <> writes:
> Still sounds good.  Do you think that this system could be extended to other 
> add-ons in the future which are currently more complex builds?  And allow us 
> to out some of the wierder things in /contrib?

The "system" already exists --- it's pgxs.  We already have a report
from Thomas Hallgren that pgxs works for building pljava, so I'm not
too concerned about assuming it can be used for the other PLs.  And
I think we have already pgxs-ified all of contrib, though that's
not the current standard method of building contrib.

I have no problem with pushing out any part of contrib that doesn't seem
tightly tied to the core server.  I'm not entirely sure where to draw
the line, but for instance I'd probably want to keep dblink where it is,
since functions-returning-records are still in considerable flux.
        regards, tom lane


Re: [pgsql-advocacy] Increased company involvement

From
Josh Berkus
Date:
Tom,

> I have no problem with pushing out any part of contrib that doesn't seem
> tightly tied to the core server.  I'm not entirely sure where to draw
> the line, but for instance I'd probably want to keep dblink where it is,
> since functions-returning-records are still in considerable flux.

Yes, I wanted to discuss this on a module-by-module basis before feature
freeze.  Will post my notes on it in a couple weeks.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Thu, 5 May 2005, Tom Lane wrote:

> Josh Berkus <> writes:
>> Still sounds good.  Do you think that this system could be extended to other
>> add-ons in the future which are currently more complex builds?  And allow us
>> to out some of the wierder things in /contrib?
>
> The "system" already exists --- it's pgxs.  We already have a report
> from Thomas Hallgren that pgxs works for building pljava, so I'm not
> too concerned about assuming it can be used for the other PLs.  And
> I think we have already pgxs-ified all of contrib, though that's
> not the current standard method of building contrib.
>
> I have no problem with pushing out any part of contrib that doesn't seem
> tightly tied to the core server.  I'm not entirely sure where to draw
> the line, but for instance I'd probably want to keep dblink where it is,
> since functions-returning-records are still in considerable flux.

Can I suggest that we focus on PLs first and foremost, since that will 
allow us to get stuff like pl/PHP, pl/Java, pl/J(?), and pl/R in place, 
and then ramp up other stuff as time permits?

Do we want to consider adding in a "mirror" of the JDBC/ODBC stuff in the 
same way?  Based on the direction we are taking, I'm all for it .. the 
idea being that when beta starts, the JDBC folk (or ODBC, or ?) would 
submit a mega patch to be applied to the tree and tag'd in with the rest 
of it, and beta distribution copies built up ... development of the 
various drivers would remain on gborg/pgfoundry where they are now, all 
we'd have in our CVS would be 'the released version' ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Tom Lane
Date:
"Marc G. Fournier" <> writes:
> On Thu, 5 May 2005, Tom Lane wrote:
>> I have no problem with pushing out any part of contrib that doesn't seem
>> tightly tied to the core server.

> Can I suggest that we focus on PLs first and foremost, since that will 
> allow us to get stuff like pl/PHP, pl/Java, pl/J(?), and pl/R in place, 
> and then ramp up other stuff as time permits?

Agreed.

> Do we want to consider adding in a "mirror" of the JDBC/ODBC stuff in the 
> same way?

I would vote not, since those projects are the exact opposite of the PLs
in terms of the degree of coupling with the backend.  Not only do they
not care at all about backend internal APIs, but they go out of their
way to work with multiple backend versions, and so their release cycles
aren't tied to the core.  We pushed JDBC/ODBC out of the core for good
reasons and I don't see adding them back in.

This is not to say that we might not want to adjust our distribution
setup so that it's easier for people to find 'em --- that is, we could
put JDBC/ODBC tarballs on the main ftp servers.  But I don't see the
need for any coupling inside CVS.
        regards, tom lane


Re: [pgsql-advocacy] Increased company involvement

From
Andrew Dunstan
Date:

Marc G. Fournier wrote:

>
> Do we want to consider adding in a "mirror" of the JDBC/ODBC stuff in 
> the same way?  Based on the direction we are taking, I'm all for it .. 
> the idea being that when beta starts, the JDBC folk (or ODBC, or ?) 
> would submit a mega patch to be applied to the tree and tag'd in with 
> the rest of it, and beta distribution copies built up ... development 
> of the various drivers would remain on gborg/pgfoundry where they are 
> now, all we'd have in our CVS would be 'the released version' ...
>
>

This is just a horrible horrible idea. Code needs to have one 
authoritative home. I know the dreadful fate of Cassandra, but please 
think very carefully about this. The "mega patch just before release" 
would bite quite horribly. I have had to manage projects where we had to 
sync between repos - even in a much smaller more manageable commercial 
environment it sucked badly, and we quickly abandoned it.

cheers

andrew


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Thu, 5 May 2005, Tom Lane wrote:

>> Can I suggest that we focus on PLs first and foremost, since that will
>> allow us to get stuff like pl/PHP, pl/Java, pl/J(?), and pl/R in place,
>> and then ramp up other stuff as time permits?
>
> Agreed.

'k, if there are no disagreements ... I can't see there being much we need 
to do to "get started" ... I don't need a "fully working and buildable 
package" to do the initial module load in CVS, so I think its pretty safe 
to say "anyone that has an "external PL" that they wish to have as a 
module (not integrated with the core distribution, only on the core CVS 
server), please send me a tar file of what they wish to have imported, and 
I can get that done.  Once that is done, I can work up the mk-snapshot 
script to build 'snapshot distributions' of the various modules as well 
...

> This is not to say that we might not want to adjust our distribution 
> setup so that it's easier for people to find 'em --- that is, we could 
> put JDBC/ODBC tarballs on the main ftp servers.  But I don't see the 
> need for any coupling inside CVS.

Hrmmm, that  would be a bit more difficult, but I could extend the 
distribution build scripts so that they do an export from CVSROOTs housed 
on pgfoundry based on code "at the time of" the distribution build ... 
hrmmm, even better ...

mk_snapshot would build off of -HEAD, which is what it does now

when we go beta for the core distribution, external projects would be 
required to tag/branch their own branch equivalent to the one we are 
basing a release off of, so that what we are pulling is less of a moving 
target then the -HEAD would potentially be ... basically, there has to be 
a tag/branch equivalent to that for which we are about to release ...

it wouldn't be much more work on our side, since I should be able to 
easily script for it, it would just mean that projects like 
JDBC/libpqxx/ODBC would need to setup an appropriate tag at varoius points 
in development so that they get included ...

So, what we'd be looking at is pretty much any driver/interface 
could potentially be included, and if the tag doesn't exist (ie. nobody is 
maintaining it), it wouldn't be included in that "release" ...

Sound reasonable?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Alvaro Herrera
Date:
On Thu, May 05, 2005 at 03:25:45PM -0300, Marc G. Fournier wrote:

> 'k, if there are no disagreements ... I can't see there being much we need 
> to do to "get started" ... I don't need a "fully working and buildable 
> package" to do the initial module load in CVS, so I think its pretty safe 
> to say "anyone that has an "external PL" that they wish to have as a 
> module (not integrated with the core distribution, only on the core CVS 
> server), please send me a tar file of what they wish to have imported, and 
> I can get that done.  Once that is done, I can work up the mk-snapshot 
> script to build 'snapshot distributions' of the various modules as well 
> ...

Huh, so you would install a snapshot and lose all previous history?

-- 
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
Bob [Floyd] used to say that he was planning to get a Ph.D. by the "green
stamp method," namely by saving envelopes addressed to him as 'Dr. Floyd'.
After collecting 500 such letters, he mused, a university somewhere in
Arizona would probably grant him a degree.              (Don Knuth)


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Thu, 5 May 2005, Alvaro Herrera wrote:

> On Thu, May 05, 2005 at 03:25:45PM -0300, Marc G. Fournier wrote:
>
>> 'k, if there are no disagreements ... I can't see there being much we need
>> to do to "get started" ... I don't need a "fully working and buildable
>> package" to do the initial module load in CVS, so I think its pretty safe
>> to say "anyone that has an "external PL" that they wish to have as a
>> module (not integrated with the core distribution, only on the core CVS
>> server), please send me a tar file of what they wish to have imported, and
>> I can get that done.  Once that is done, I can work up the mk-snapshot
>> script to build 'snapshot distributions' of the various modules as well
>> ...
>
> Huh, so you would install a snapshot and lose all previous history?

If you want to pass over your CVS tree, I'd not be adverse to that either 
... its easy enough to plug in :)

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Peter Eisentraut
Date:
Marc G. Fournier wrote:
> > This is not to say that we might not want to adjust our
> > distribution setup so that it's easier for people to find 'em ---
> > that is, we could put JDBC/ODBC tarballs on the main ftp servers. 
> > But I don't see the need for any coupling inside CVS.
>
> Hrmmm, that  would be a bit more difficult,

No, it just needs someone with write access to the FTP server tree to 
copy the files there once in a while, which is trivial to do.  (All the 
relevant people already have that access.)

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


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Thu, 5 May 2005, Peter Eisentraut wrote:

> Marc G. Fournier wrote:
>>> This is not to say that we might not want to adjust our
>>> distribution setup so that it's easier for people to find 'em ---
>>> that is, we could put JDBC/ODBC tarballs on the main ftp servers.
>>> But I don't see the need for any coupling inside CVS.
>>
>> Hrmmm, that  would be a bit more difficult,
>
> No, it just needs someone with write access to the FTP server tree to
> copy the files there once in a while, which is trivial to do.  (All the
> relevant people already have that access.)

'k, I think we're talking about two different things right now .. both 
jdbc and odbc *are* on the main ftp servers right now ... or, rather, 
should be if ppl uploaded their distributions to their project file 
sections:

ftp> pwd
257 "/pub/projects/gborg/pgjdbc" is current directory.

ftp> pwd
257 "/pub/projects/gborg/psqlodbc" is current directory.

gets updated hourly ...


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Robert Treat
Date:
On Thursday 05 May 2005 14:25, Marc G. Fournier wrote:
> On Thu, 5 May 2005, Tom Lane wrote:
> >> Can I suggest that we focus on PLs first and foremost, since that will
> >> allow us to get stuff like pl/PHP, pl/Java, pl/J(?), and pl/R in place,
> >> and then ramp up other stuff as time permits?
> >
> > Agreed.
>
> 'k, if there are no disagreements ...

A big reason I wanted plphp in the main souce was because I wanted it to be 
part of the core package to help ease installation to be just one download 
and one run at configure.  I have marvel at the irony that not only is this 
not going to happen, I will actually now have to download additional packages 
for things I used to get in the core package.  

I guess this is progress, but I foresee a lot of "what version of plfoo did 
you try to install against your database" posts coming into the lists.   

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


Re: [pgsql-advocacy] Increased company involvement

From
"Marc G. Fournier"
Date:
On Thu, 5 May 2005, Robert Treat wrote:

> On Thursday 05 May 2005 14:25, Marc G. Fournier wrote:
>> On Thu, 5 May 2005, Tom Lane wrote:
>>>> Can I suggest that we focus on PLs first and foremost, since that will
>>>> allow us to get stuff like pl/PHP, pl/Java, pl/J(?), and pl/R in place,
>>>> and then ramp up other stuff as time permits?
>>>
>>> Agreed.
>>
>> 'k, if there are no disagreements ...
>
> A big reason I wanted plphp in the main souce was because I wanted it to be
> part of the core package to help ease installation to be just one download
> and one run at configure.  I have marvel at the irony that not only is this
> not going to happen, I will actually now have to download additional packages
> for things I used to get in the core package.
>
> I guess this is progress, but I foresee a lot of "what version of plfoo did
> you try to install against your database" posts coming into the lists.

I think you missed a large portion of this thread ... the pls will be part 
of our core CVS repository, will be tag'd and branched at the same points 
in the development cycle, and will be released at same ... the only 
difference is that they will be a standalone download and build, but will 
still be:

plphp-8.1.0.tar.gz
pljava-8.1.0.tar.gz
etc

in fact, with how it looks like we'll end up extending it over time, there 
will also be a:

jdbc-8.1.0.tar.gz
odbc-8.1.0.tar.gz
libpqxx-8.1.0.tar.gz

all released at the same time, and tag'd the same way, and available under 
the same ftp directory ...


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: [pgsql-advocacy] Increased company involvement

From
Josh Berkus
Date:
Marc,

> all released at the same time, and tag'd the same way, and available under
> the same ftp directory ...

Hmmm.  As licensing permits, I think we should also offer a "kitchen sink" 
download for those who want it. Which a lot of people will.

I believe that GreenPlum has a serious CVS hacker who might be able to help 
with integrated build issues; I know we're looking into them for Bizgres.  
Need help?  Should I ask?

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco


'kitchen sink' downloads (Was: Re: [pgsql-advocacy] Increased company involvement)

From
"Marc G. Fournier"
Date:
On Thu, 5 May 2005, Josh Berkus wrote:

> Marc,
>
>> all released at the same time, and tag'd the same way, and available under
>> the same ftp directory ...
>
> Hmmm.  As licensing permits, I think we should also offer a "kitchen sink"
> download for those who want it. Which a lot of people will.

'k, how do you envision this?  I can do a very simple "export" into the 
same directory and tar it all up, but if you are thinking of something 
like recreating the existing directory structure, with plphp being in 
src/pl/plphp, and that sort of thing, that could be a bit more tricky ... 
not from a CVS/packaging perspective, since I've done that before, but 
running ./configure at the top level directory won't pick up them up and 
configure them, since they are all configured using their own ...

I've seen some projects where configure *calls* configure in sub 
directories ... but that becomes a build issue if someone wants to try and 
tackle that?

if directory src/pl/php exists, run configure in there with current args?



----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Marc,

> I've seen some projects where configure *calls* configure in sub
> directories ... but that becomes a build issue if someone wants to try and
> tackle that?

Yes, that's what I was proposing that I pitch to the folks at Greenplum that 
they help with.  Might be hard, though, because they're currently using ant 
for the build, and we wouldn't want to.

--Josh

-- 
__Aglio Database Solutions_______________
Josh Berkus               Consultant
     www.agliodbs.com
Ph: 415-752-2500    Fax: 415-752-2387
2166 Hayes Suite 200    San Francisco, CA


Re: 'kitchen sink' downloads (Was: Re: [pgsql-advocacy]

From
"Marc G. Fournier"
Date:
On Thu, 5 May 2005, Josh Berkus wrote:

> Marc,
>
>> I've seen some projects where configure *calls* configure in sub
>> directories ... but that becomes a build issue if someone wants to try and
>> tackle that?
>
> Yes, that's what I was proposing that I pitch to the folks at Greenplum that
> they help with.  Might be hard, though, because they're currently using ant
> for the build, and we wouldn't want to.

Let's get the individual builds working first, since I don't believe any 
of the PLs right now are ready to be "standalone builds"?  Then we can 
look into 'integrating' them into one 'kitchen sink tar ball', once we 
have something to work with ...

Once we have the first one in place, I'll modify mk-snapshot so that it 
does its regular 'make dist-split' for the 'core', does a tar ball for the 
pl, and also does a 'meta package' that includes both, to give a 'base' to 
work from ...

But we need at least one of them ready for a standalone build first ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: 'kitchen sink' downloads (Was: Re: [pgsql-advocacy]

From
Thomas Hallgren
Date:
Marc G. Fournier wrote:

> But we need at least one of them ready for a standalone build first ...
> 
PL/Java might be ready. Depends on your definition of "standalone build" 
of course. Can you elaborate?

Regards,
Thomas Hallgren



Re: 'kitchen sink' downloads (Was: Re: [pgsql-advocacy]

From
"Marc G. Fournier"
Date:
On Thu, 5 May 2005, Thomas Hallgren wrote:

> Marc G. Fournier wrote:
>
>> But we need at least one of them ready for a standalone build first ...
>> 
> PL/Java might be ready. Depends on your definition of "standalone build" of 
> course. Can you elaborate?

could I download a tar file to my machine that already has 
include/header files install and build it without having to download the 
postgresql source tree too?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: 'kitchen sink' downloads (Was: Re: [pgsql-advocacy]

From
Thomas Hallgren
Date:
Marc G. Fournier wrote:
> On Thu, 5 May 2005, Thomas Hallgren wrote:
> 
>> Marc G. Fournier wrote:
>>
>>> But we need at least one of them ready for a standalone build first ...
>>>
>> PL/Java might be ready. Depends on your definition of "standalone 
>> build" of course. Can you elaborate?
> 
> 
> could I download a tar file to my machine that already has 
> include/header files install and build it without having to download the 
> postgresql source tree too?
> 
You need to have a PostgreSQL (binary) installed. There's no need for 
the source.

- thomas



Re: 'kitchen sink' downloads (Was: Re: [pgsql-advocacy]

From
"Marc G. Fournier"
Date:
On Fri, 6 May 2005, Thomas Hallgren wrote:

> Marc G. Fournier wrote:
>> On Thu, 5 May 2005, Thomas Hallgren wrote:
>> 
>>> Marc G. Fournier wrote:
>>> 
>>>> But we need at least one of them ready for a standalone build first ...
>>>> 
>>> PL/Java might be ready. Depends on your definition of "standalone build" 
>>> of course. Can you elaborate?
>> 
>> 
>> could I download a tar file to my machine that already has include/header 
>> files install and build it without having to download the postgresql source 
>> tree too?
>> 
> You need to have a PostgreSQL (binary) installed. There's no need for the 
> source.

so,I could download this to my already installed server and build it? 
that is exactly what we are looking for ...


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664


Re: 'kitchen sink' downloads (Was: Re: [pgsql-advocacy]

From
Thomas Hallgren
Date:
Marc G. Fournier wrote:

> On Fri, 6 May 2005, Thomas Hallgren wrote:
>
>> Marc G. Fournier wrote:
>>
>>> On Thu, 5 May 2005, Thomas Hallgren wrote:
>>>
>>>> Marc G. Fournier wrote:
>>>>
>>>>> But we need at least one of them ready for a standalone build 
>>>>> first ...
>>>>>
>>>> PL/Java might be ready. Depends on your definition of "standalone 
>>>> build" of course. Can you elaborate?
>>>
>>>
>>>
>>> could I download a tar file to my machine that already has 
>>> include/header files install and build it without having to download 
>>> the postgresql source tree too?
>>>
>> You need to have a PostgreSQL (binary) installed. There's no need for 
>> the source.
>
>
> so,I could download this to my already installed server and build it? 
> that is exactly what we are looking for ...

Sure. PL/Java has 2 requirements for building. One is that PostgreSQL is 
installed. The other is that you have either GNU GCJ or a JDK installed.

I think it would be possible to completely remove the second requirement 
by bundling a Java Native Interface (JNI) header file and a dummy 
library but it's not done that way today and I haven't investigated what 
license restrictions that might apply. Let me know if you think that's 
worth investigating.

Regards,
Thomas Hallgren




Re: 'kitchen sink' downloads (Was: Re: [pgsql-advocacy]

From
"Marc G. Fournier"
Date:
On Fri, 6 May 2005, Thomas Hallgren wrote:

> Sure. PL/Java has 2 requirements for building. One is that PostgreSQL is 
> installed. The other is that you have either GNU GCJ or a JDK installed.

These are both fine ... please note we aren't saying that it has to be 
pre-built, only that it can't *require* the postgresql sources to be 
available ... plphp will still require php4 to be installed before hand, 
pl/R would still require the R stuff, etc ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email:            Yahoo!: yscrappy              ICQ: 7615664