Thread: Re: [pgsql-advocacy] Increased company involvement
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > 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
> > 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/
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 pgman@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
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 pgman@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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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 pgman@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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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 pgman@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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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 pgman@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
> > > 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: scrappy@hub.org 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/
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
>> >> 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: scrappy@hub.org 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/
"Marc G. Fournier" <scrappy@postgresql.org> 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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> > 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/
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 pgman@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
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 pgman@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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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 pgman@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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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: scrappy@hub.org 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/
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 pgman@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
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/
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Bruce Momjian <pgman@candle.pha.pa.us> 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
On Mon, May 02, 2005 at 12:39:27PM -0500, Dave Held wrote: > > -----Original Message----- > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > 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 decibel@decibel.org 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?"
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
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?
>>> >>> 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/
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
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 decibel@decibel.org 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?"
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
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)
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@navtechinc.com) (ssinger does submit patches for it on a reasonably regular basis.) -Neil
> > 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
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/
* Peter Eisentraut (peter_e@gmx.net) 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
Peter Eisentraut <peter_e@gmx.net> 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
Stephen Frost wrote: > * Peter Eisentraut (peter_e@gmx.net) 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
On Tue, 3 May 2005, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> 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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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/
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
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/
> > 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: scrappy@hub.org 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/
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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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/
>> >> 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/
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> > 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/
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
Robert Treat <xzilla@users.sourceforge.net> 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
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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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
* Robert Treat (xzilla@users.sourceforge.net) 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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Robert Treat <xzilla@users.sourceforge.net> 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
* Marc G. Fournier (scrappy@postgresql.org) 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
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
* Marc G. Fournier (scrappy@postgresql.org) 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
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/
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> > > 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: scrappy@hub.org 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/
* Peter Eisentraut (peter_e@gmx.net) 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
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
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: scrappy@hub.org 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 majordomo@postgresql.org) > > -- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561
On Tuesday 03 May 2005 13:51, Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> 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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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/
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: scrappy@hub.org Yahoo!: yscrappy ICQ: > 7615664 > > -- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Monday 02 May 2005 15:12, Tom Lane wrote:
> "Marc G. Fournier" <scrappy@postgresql.org> 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
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 pgman@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
Bruce Momjian <pgman@candle.pha.pa.us> 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
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> 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 majordomo@postgresql.org 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
On Wed, 4 May 2005, Joshua D. Drake wrote: > Tom Lane wrote: >> Bruce Momjian <pgman@candle.pha.pa.us> 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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> 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
Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> 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
"Joshua D. Drake" <jd@commandprompt.com> 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
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
Josh Berkus <josh@agliodbs.com> 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
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...)
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="mid19337.1115269700@sss.pgh.pa.us"
type="cite"><prewrap="">"Joshua D. Drake" <a class="moz-txt-link-rfc2396E"
href="mailto:jd@commandprompt.com"><jd@commandprompt.com></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:majordomo@postgresql.org">majordomo@postgresql.org</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>
Joe Conway <mail@joeconway.com> 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
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" <jd@commandprompt.com> 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 majordomo@postgresql.org) >> >> >> > > -- > Dave Cramer > http://www.postgresintl.com > 519 939 0336 > ICQ#14675561 > > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> 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
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" <scrappy@postgresql.org> 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
On Thu, 5 May 2005, Tom Lane wrote:
> "Marc G. Fournier" <scrappy@postgresql.org> 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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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
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/
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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
"Marc G. Fournier" <scrappy@postgresql.org> 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
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
Josh Berkus <josh@agliodbs.com> 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
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
On Thu, 5 May 2005, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> 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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Thu, 5 May 2005, Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> 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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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
Josh Berkus <josh@agliodbs.com> 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
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
On Thu, 5 May 2005, Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> 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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> 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
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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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)
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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/
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Re: 'kitchen sink' downloads (Was: Re: [pgsql-advocacy] Increased company involvement)
From
Josh Berkus
Date:
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 josh@agliodbs.com www.agliodbs.com Ph: 415-752-2500 Fax: 415-752-2387 2166 Hayes Suite 200 San Francisco, CA
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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
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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664