Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: As far as I know, PLs or contrib files *aren't* tested by the regression tests, so, at best, they are getting 'spotty testing' right now when we release ... we know they build, that's it. And that won't change before/after ... Andrew is looking to add PL testing to the build farm, something that isn't done now ... contrib modules with install checks are tested now on buildfarm, and have been from day one. PL testing is a high priority - I hope to get it done this month before my trip to aus. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Fri, 6 May 2005, Dave Page wrote: Yes, but isn't the point of the so-called WTKS to pull in other projects like PL/R, libpqxx and a range of other external projects from places like Gborg? We have precisely zero control over their quality. Course we have control over it ... if it isn't up to snuff, we just don't include it ... its not much different then if we were to pull them all into our core CVS, but nobody ever tests them when we release ... other then 'ensuring it builds', unless someone actively tested libpqxx, or JDBC, or ODBC when they were in our "core CVS", those went out with the "presumption" of the "same quality as the rest of the code", but they could have had the biggest bugs in them that nobody would know about ... So we could easily end up with one package being included in one release, but not the next, then included in the next two, then dropped from a couple? Users will go loopy trying to figure that out! True ... there has to be some sort of decision process for what to include other then just arbitrarily adding things ... personally, I'm only currently looking at our current core CVS, with 'external stuff' being something we *could* do ... some stuff, I'm fairly confident could be easily/safely done, like JDBC, since those folks are active on these lists ... I don't know if libpqxx folks are around here, but if they were, one would expect them to make their voice heard ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Fri, 6 May 2005, Stephen Frost wrote: Honestly, I think WTKS will work for you, though you may end up downloading more than you want and you'll have to ignore build failures for those PLs you don't have the interpreters for. Actually, that shouldn't be an issue ... the WTKS tar ball would have a configure like we have now: ./configure --with-python so that you could pick-n-choose which ones to build ... or, rather, it should be smarter yet and be able to determine that libpython is available or not, and build accordingly ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
* Magnus Hagander ([EMAIL PROTECTED]) wrote: > If you are on debian or a derivative, of course. I assume we are not > planning to abandon the users who build from source. Not abandon them, no. That's where Marc's stuff comes into play really, and the WTKS stuff. > (won't using apt-get get you a pre-8.0 version, btw? :P) Not if you're using the Debian/experimental repository. :) > Why may it need to be done? If the build issue can be solved, I'm sure > the packaging can be solved at least as easy. Because core isn't going to maintain them all forever, not that it sounds like much is done to maintain them currently anyway... Also, as people become aware that it's easier to write PLs for Postgres there may be more showing up (ruby, for example). I don't *know* any of this for sure, but it certainly seems like it'll happen eventually. > > Perhaps the interfaces are still in alot of flux, but this is > > actually not exactly unheard of when things start taking off > > more and more- the big universal package gets split up with > > well defined interfaces into seperate pieces so that new > > pieces can be created more easily and maintained in a > > distributed manner. > > In this discussion, I don't care where they are maintained - core cvs, > separate cvs, etc. I care where they are packaged for download - the > tar.gz files. They can be maintained elsewhere for all I care (though I > do see the points of keeping them in there, in order to track API > changes etc), as long as they are still pulled into the main tarball. > I'm concerned with making things easy for the *user*. Splitting it up > may (though I'm not convinved of that part) make it easier for the > *developer*, but certainly not for the *user*. The source user- perhaps not. Then again, the source user may not want to build every PL, and thus have to have the build requirements for every PL that's in PostgreSQL. This starts to become a 'where do you draw the line' question. Marc's talking about adding more stuff into WTKS than you'd like, but why shouldn't they go in there? Because they'd add additional build dependencies you don't want to have to worry about? What about that person who doesn't want to have to have PL/Python or Python installed at all? Honestly, I think WTKS will work for you, though you may end up downloading more than you want and you'll have to ignore build failures for those PLs you don't have the interpreters for. If you want it more granular than that then you're going to have to download them individually unless you can come up with a sensible line that Marc agrees is useful enough to add yet-another tarball for. Stephen signature.asc Description: Digital signature
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Fri, 6 May 2005, Magnus Hagander wrote: For PLs, usually I do. Then I activate them as they are needed. For contribs, no, I usually stick tsearch2 in there, but not many other contribs. See, me, I download/install a PL as required ... so being able to download a nice tiny file that uses my existing libs/headers is optimal ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> -Original Message- > From: Marc G. Fournier [mailto:[EMAIL PROTECTED] > Sent: 06 May 2005 16:04 > To: Dave Page > Cc: Marc G. Fournier; Magnus Hagander; Robert Treat; Tom > Lane; Josh Berkus; pgsql-hackers@postgresql.org > Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement > > On Fri, 6 May 2005, Dave Page wrote: > > > - Who/how will the release processes for all these seperate > projects be > > coordinated? > > Who does now? As far as I know, PLs or contrib files > *aren't* tested by > the regression tests, so, at best, they are getting 'spotty > testing' right > now when we release ... we know they build, that's it. And > that won't > change before/after ... Andrew is looking to add PL testing > to the build > farm, something that isn't done now ... Yes, but isn't the point of the so-called WTKS to pull in other projects like PL/R, libpqxx and a range of other external projects from places like Gborg? We have precisely zero control over their quality. > > - How will users be sure that the external projects are of > the quality > > we expect of PostgreSQL? > > Again, how are they sure now? > > If you are referring to my thought to include stuff like JDBC > or libpqxx, > then as I've already stated, it will be their responsibility > to work with > us if they want to be included ... if we are ready to release > 8.1, and > they don't set down a 8.1 tag that we can 'pull from', they won't be > included in that release ... we're not going to chase them down ... So we could easily end up with one package being included in one release, but not the next, then included in the next two, then dropped from a couple? Users will go loopy trying to figure that out! Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Fri, 6 May 2005, Dave Page wrote: - Who/how will the release processes for all these seperate projects be coordinated? Who does now? As far as I know, PLs or contrib files *aren't* tested by the regression tests, so, at best, they are getting 'spotty testing' right now when we release ... we know they build, that's it. And that won't change before/after ... Andrew is looking to add PL testing to the build farm, something that isn't done now ... - How will users be sure that the external projects are of the quality we expect of PostgreSQL? Again, how are they sure now? If you are referring to my thought to include stuff like JDBC or libpqxx, then as I've already stated, it will be their responsibility to work with us if they want to be included ... if we are ready to release 8.1, and they don't set down a 8.1 tag that we can 'pull from', they won't be included in that release ... we're not going to chase them down ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> What is being worked on right now is effectively reducing > >> things down > to: > > postgresql-server (including libpq) postgresql- add on here> > >>> > >>> So you mean to get an equivalent of > >> postgresql-8.0.2.tar.bz2, I will > >>> have to download 30+ tarballs? > >> > >> Or the WTKS one ... which will exist from day one, but not as > >> "integrated" > >> as Josh would like us to get to eventually ... > > > > I assume "as integrated as today", meaning I still only > need to do one > > "./configure" and one "make"? > > Correct, it may be something that someone can figure out how > to do easily (or, already knows how to do) though ... just > haven't had anyone step up to the plate on it, and don't > expect someone to until there is something for them to base > the work on. Ok. As long as I can do that (and as long as it's not named -WTKS- :P), I'm fine (since I'm basically not affected). And assuming that the standards applied to get into the wkts file is about the same as we have now for code quality etc. And as long as nothing is ripped until it actually works :) > > If not then it really takes away much of the point, doing "mget > > *.tar.gz" isn't that much harder than specifying a file.. > > If you seriously install *every* PL and every contrib file on > your server, then that is an option ... For PLs, usually I do. Then I activate them as they are needed. For contribs, no, I usually stick tsearch2 in there, but not many other contribs. //Magnus ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Fri, 6 May 2005, Magnus Hagander wrote: What is being worked on right now is effectively reducing things down to: postgresql-server (including libpq) postgresql- So you mean to get an equivalent of postgresql-8.0.2.tar.bz2, I will have to download 30+ tarballs? Or the WTKS one ... which will exist from day one, but not as "integrated" as Josh would like us to get to eventually ... I assume "as integrated as today", meaning I still only need to do one "./configure" and one "make"? Correct, it may be something that someone can figure out how to do easily (or, already knows how to do) though ... just haven't had anyone step up to the plate on it, and don't expect someone to until there is something for them to base the work on. If not then it really takes away much of the point, doing "mget *.tar.gz" isn't that much harder than specifying a file.. If you seriously install *every* PL and every contrib file on your server, then that is an option ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> -Original Message- > From: Marc G. Fournier [mailto:[EMAIL PROTECTED] > Sent: 06 May 2005 15:35 > To: Dave Page > Cc: Marc G. Fournier; Magnus Hagander; Robert Treat; Tom > Lane; Josh Berkus; pgsql-hackers@postgresql.org > Subject: RE: [pgsql-advocacy] [HACKERS] Increased company involvement > > On Fri, 6 May 2005, Dave Page wrote: > > > > > > >> -Original Message- > >> From: Marc G. Fournier [mailto:[EMAIL PROTECTED] > >> Sent: 06 May 2005 01:15 > >> To: Magnus Hagander > >> Cc: Marc G. Fournier; Dave Page; Robert Treat; Tom Lane; Josh > >> Berkus; pgsql-hackers@postgresql.org > >> Subject: Re: [pgsql-advocacy] [HACKERS] Increased company > involvement > >> > >> What is being worked on right now is effectively reducing > >> things down to: > >> > >> postgresql-server (including libpq) > >> postgresql- > > > > So you mean to get an equivalent of postgresql-8.0.2.tar.bz2, I will > > have to download 30+ tarballs? > > Or the WTKS one ... which will exist from day one, but not as > "integrated" > as Josh would like us to get to eventually ... Which will soon bloat to an incredible size as everything under the sun gets added? A couple of questions though: - Who/how will the release processes for all these seperate projects be coordinated? - How will users be sure that the external projects are of the quality we expect of PostgreSQL? Asking as someone who only uses the full tarball and doesn't want the kitchen sink and half of Gborg as well, please do not get rid of the current full distribution. Regards, Dave ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> >> What is being worked on right now is effectively reducing > things down > >> to: > >> > >> postgresql-server (including libpq) > >> postgresql- > > > > So you mean to get an equivalent of > postgresql-8.0.2.tar.bz2, I will > > have to download 30+ tarballs? > > Or the WTKS one ... which will exist from day one, but not as > "integrated" > as Josh would like us to get to eventually ... I assume "as integrated as today", meaning I still only need to do one "./configure" and one "make"? If not then it really takes away much of the point, doing "mget *.tar.gz" isn't that much harder than specifying a file.. //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Fri, 6 May 2005, Peter Eisentraut wrote: Am Donnerstag, 5. Mai 2005 23:47 schrieb Marc G. Fournier: have against is that the names could get very long: postgresql-fuzzystrmatch-8.0.2.tar.gz the postgresql part just seems redundant ... Not once you have downloaded it and don't remember where you got it from. Agreed ... not arguing against, just wish there was some 'magical way' that the translation could be down while downloading (I know, there isn't, just wishful thinking on my part) ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Fri, 6 May 2005, Dave Page wrote: -Original Message- From: Marc G. Fournier [mailto:[EMAIL PROTECTED] Sent: 06 May 2005 01:15 To: Magnus Hagander Cc: Marc G. Fournier; Dave Page; Robert Treat; Tom Lane; Josh Berkus; pgsql-hackers@postgresql.org Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement What is being worked on right now is effectively reducing things down to: postgresql-server (including libpq) postgresql- So you mean to get an equivalent of postgresql-8.0.2.tar.bz2, I will have to download 30+ tarballs? Or the WTKS one ... which will exist from day one, but not as "integrated" as Josh would like us to get to eventually ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
* Adrian Maier ([EMAIL PROTECTED]) wrote: > Once this 'wtks' will be available, I bet that most people who are > aware of its existance will prefer to download it because it would > be much more convenient.The name of the package will need > to be carefully chosen, though. "wtks" does not seem to be a good > choice ( native English speakers surely know what is a 'kitchen sink', > but I really don't understand what it means) . Much more convenient for an end user who *wants* all of the PLs, and already has all of the various build dependencies available on their system, which, btw, I expect more will probably be added, and is building from source. Certainly not more convenient for the user using a binary distribution- rather a headache if they *don't* want to install every language interpreter that someone's made into a PL for Postgres. > Just wondering: would it be feasible to expand the existing contrib > directory to a system similar to the BSD ports collection ? > One would type: > cd postgresql-8.1.0/contrib/pls/pljava > make install > ( which would download the pljava sources from pgfoundry, > build it and install ) > > With such a system in place, various modules could be installed > in a unique manner no matter where they are hosted. And they > would gain visibility ... This seems a great deal like what's under discussion already, except that it wouldn't be under the postgresql-8.1.0 source directory but rather in a seperate module. I don't really see much difference between what you're suggesting and what's being proposed. Thanks, Stephen signature.asc Description: Digital signature
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> > Remind me again how this is actually *better*, and not just making > > life a whole lot worse for me? And more specifically, for a > new user > > that doesn't know which files to download already, and will > just grab > > the default file. > > Or the new user will go 'apt-get install postgresql' and have > all the various packages downloaded and installed for them. > Alternatively, if they only *want* the server and not every > PL under the moon, with all the various dependencies that may > involve, then can 'apt-get install postgresql-server'. Big > win for me. If you are on debian or a derivative, of course. I assume we are not planning to abandon the users who build from source. (won't using apt-get get you a pre-8.0 version, btw? :P) > > Pulling the interfaces out of the main tarball was bad > enough, but it > > had point - ODBC and JDBC need to work with different versions, and > > may be released as different times. Please don't do the > same for PLs. > > It may need to be done for PLs in the end, especially as more > and more are done (which may happen once it's made easier to > do, and examples are available, and something that anyone > could do on their own and provide a sensible build for, since > it doesn't have to be in the main build tree). Why may it need to be done? If the build issue can be solved, I'm sure the packaging can be solved at least as easy. > Perhaps the interfaces are still in alot of flux, but this is > actually not exactly unheard of when things start taking off > more and more- the big universal package gets split up with > well defined interfaces into seperate pieces so that new > pieces can be created more easily and maintained in a > distributed manner. In this discussion, I don't care where they are maintained - core cvs, separate cvs, etc. I care where they are packaged for download - the tar.gz files. They can be maintained elsewhere for all I care (though I do see the points of keeping them in there, in order to track API changes etc), as long as they are still pulled into the main tarball. I'm concerned with making things easy for the *user*. Splitting it up may (though I'm not convinved of that part) make it easier for the *developer*, but certainly not for the *user*. //Magnus ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
* Magnus Hagander ([EMAIL PROTECTED]) wrote: > Remind me again how this is actually *better*, and not just making life > a whole lot worse for me? And more specifically, for a new user that > doesn't know which files to download already, and will just grab the > default file. Or the new user will go 'apt-get install postgresql' and have all the various packages downloaded and installed for them. Alternatively, if they only *want* the server and not every PL under the moon, with all the various dependencies that may involve, then can 'apt-get install postgresql-server'. Big win for me. > Pulling the interfaces out of the main tarball was bad enough, but it > had point - ODBC and JDBC need to work with different versions, and may > be released as different times. Please don't do the same for PLs. It may need to be done for PLs in the end, especially as more and more are done (which may happen once it's made easier to do, and examples are available, and something that anyone could do on their own and provide a sensible build for, since it doesn't have to be in the main build tree). Perhaps the interfaces are still in alot of flux, but this is actually not exactly unheard of when things start taking off more and more- the big universal package gets split up with well defined interfaces into seperate pieces so that new pieces can be created more easily and maintained in a distributed manner. Thanks, Stephen signature.asc Description: Digital signature
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Am Donnerstag, 5. Mai 2005 23:47 schrieb Marc G. Fournier: > have against is that the names could get very long: > > postgresql-fuzzystrmatch-8.0.2.tar.gz > > the postgresql part just seems redundant ... Not once you have downloaded it and don't remember where you got it from. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On 5/6/05, Magnus Hagander <[EMAIL PROTECTED]> wrote: > > > Actually, if the number of "split files" (whatever their names) > > > > >>postgresql-WTKS.tar.gz (with the kitchen sink) file > > that contained > > >> everything for those that really wanted to download "it all" ... > > > > > > That would be "postgresql-x.y.z.tar.gz", right? ;-) > > > > Nope, postgresql-x.y.z.tar.gz will just be the core > > distribution ...the WTKS will be the 'with the kitchen sink' > > meta distribution and would be in the subdir that you propose > > above ... in fact, I doubt that the WTKS will even be ready > > for the next release, as it will involve alot of work on the > > build system itself, I would think ... the 'cascading > > configure's could be interesting in itself ... > > Please. *Nobody* will know what postgresql-wkts-x.y.z.tar.gz is. It's > hard enough to understand the splits as they are now (what really is in > -opt for example? I know it's in the readme, but users don't read that), > and this will certainly not make it easier. Hello, If I understood correctly, this 'wtks' distribution will contain what is now in the postgresql-?.?.?.tar.gz , plus other additional things like additional PLs ( which now have to be downloaded and compiled separately ) ?Seems to be a great idea , but i agree that the contents of the postgresql-?.?.?.tar.gz tarballs should not be reduced ! Once this 'wtks' will be available, I bet that most people who are aware of its existance will prefer to download it because it would be much more convenient.The name of the package will need to be carefully chosen, though. "wtks" does not seem to be a good choice ( native English speakers surely know what is a 'kitchen sink', but I really don't understand what it means) . Just wondering: would it be feasible to expand the existing contrib directory to a system similar to the BSD ports collection ? One would type: cd postgresql-8.1.0/contrib/pls/pljava make install ( which would download the pljava sources from pgfoundry, build it and install ) With such a system in place, various modules could be installed in a unique manner no matter where they are hosted. And they would gain visibility ... Best wishes, Adrian Maier > > > Bottom line - make it easy for the *newbies*. Those of us who know > > > exactly what we want will know where to look for it (say in > > a separate > > > subdir). (or we'll just download the whole tarball anyway > > because that > > > is *way* much more convenient... Speaking for myself there, of > > > course.) > > > > Note that "the whole tar ball" will give you the core server > > and that is it ... the WTKS is a whole seperate project from > > what is being planned ... > > > > What is being worked on right now is effectively reducing > > things down to: > > > > postgresql-server (including libpq) > > postgresql- > > Um. So instead of as I do today: > wget > http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po > stgresql-8.0.2.tar.bz2 > tar xjf postgresql-8.0.2.tar.bz2 > ./configure --with-perl --with-python --with-tcl > gmake && gmake install > > I'll now have to do: > wget > http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po > stgresql-docs-8.0.2.tar.bz2 > tar xjf postgresql-docs-8.0.2.tar.bz2 > ./configure > gmake && gmake install > > Remind me again how this is actually *better*, and not just making life > a whole lot worse for me? And more specifically, for a new user that > doesn't know which files to download already, and will just grab the > default file. > > Pulling the interfaces out of the main tarball was bad enough, but it > had point - ODBC and JDBC need to work with different versions, and may > be released as different times. Please don't do the same for PLs. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> > Actually, if the number of "split files" (whatever their names) > > increase even further, may I suggest they are moved into a > subdir of > > their own, keeping just the main distribution and the > README about the > > splits in the main dir? > > the "main distribution" will just be > postgresql-server-.tar.gz > ... Ok. Then I definitly change my stand from "indifferent" to "strongly against". > >>postgresql-WTKS.tar.gz (with the kitchen sink) file > that contained > >> everything for those that really wanted to download "it all" ... > > > > That would be "postgresql-x.y.z.tar.gz", right? ;-) > > Nope, postgresql-x.y.z.tar.gz will just be the core > distribution ...the WTKS will be the 'with the kitchen sink' > meta distribution and would be in the subdir that you propose > above ... in fact, I doubt that the WTKS will even be ready > for the next release, as it will involve alot of work on the > build system itself, I would think ... the 'cascading > configure's could be interesting in itself ... Please. *Nobody* will know what postgresql-wkts-x.y.z.tar.gz is. It's hard enough to understand the splits as they are now (what really is in -opt for example? I know it's in the readme, but users don't read that), and this will certainly not make it easier. And please absolutely do *NOT* rip anything out of the main one until the replacement is ready! > > Bottom line - make it easy for the *newbies*. Those of us who know > > exactly what we want will know where to look for it (say in > a separate > > subdir). (or we'll just download the whole tarball anyway > because that > > is *way* much more convenient... Speaking for myself there, of > > course.) > > Note that "the whole tar ball" will give you the core server > and that is it ... the WTKS is a whole seperate project from > what is being planned ... > > What is being worked on right now is effectively reducing > things down to: > > postgresql-server (including libpq) > postgresql- Um. So instead of as I do today: wget http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po stgresql-8.0.2.tar.bz2 tar xjf postgresql-8.0.2.tar.bz2 ./configure --with-perl --with-python --with-tcl gmake && gmake install I'll now have to do: wget http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po stgresql-docs-8.0.2.tar.bz2 tar xjf postgresql-docs-8.0.2.tar.bz2 ./configure gmake && gmake install wget http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po stgresql-test-8.0.2.tar.bz2 tar xjf postgresql-test-8.0.2.tar.bz2 ./configure gmake && gmake install wget http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po stgresql-plperl-8.0.2.tar.bz2 tar xjf postgresql-plperl-8.0.2.tar.bz2 ./configure gmake && gmake install wget http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po stgresql-plpython-8.0.2.tar.bz2 tar xjf postgresql-plpython-8.0.2.tar.bz2 ./configure gmake && gmake install wget http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po stgresql-pltcl-8.0.2.tar.bz2 tar xjf postgresql-pltcl-8.0.2.tar.bz2 ./configure gmake && gmake install Remind me again how this is actually *better*, and not just making life a whole lot worse for me? And more specifically, for a new user that doesn't know which files to download already, and will just grab the default file. Pulling the interfaces out of the main tarball was bad enough, but it had point - ODBC and JDBC need to work with different versions, and may be released as different times. Please don't do the same for PLs. //Magnus ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> -Original Message- > From: Marc G. Fournier [mailto:[EMAIL PROTECTED] > Sent: 06 May 2005 01:15 > To: Magnus Hagander > Cc: Marc G. Fournier; Dave Page; Robert Treat; Tom Lane; Josh > Berkus; pgsql-hackers@postgresql.org > Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement > > What is being worked on right now is effectively reducing > things down to: > > postgresql-server (including libpq) > postgresql- So you mean to get an equivalent of postgresql-8.0.2.tar.bz2, I will have to download 30+ tarballs? /D ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> -Original Message- > From: Magnus Hagander [mailto:[EMAIL PROTECTED] > Sent: 05 May 2005 22:58 > To: Marc G. Fournier; Dave Page > Cc: Robert Treat; Tom Lane; Josh Berkus; pgsql-hackers@postgresql.org > Subject: SV: [pgsql-advocacy] [HACKERS] Increased company involvement > > > postgresql-WTKS.tar.gz (with the kitchen sink) file > >that contained > >everything for those that really wanted to download "it all" ... > > That would be "postgresql-x.y.z.tar.gz", right? ;-) I'm not sure based on the current discussion. The file above is what I always download, and what I will want to download in the future. I kinda got the impression that WTKS would include all sorts of other stuff which I would not be interested in. > Bottom line - make it easy for the *newbies*. Those of us who know > exactly what we want will know where to look for it (say in a separate > subdir). (or we'll just download the whole tarball anyway because that > is *way* much more convenient... Speaking for myself there, > of course.) Agreed on all counts. /D ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Thu, 5 May 2005, Magnus Hagander wrote: Actually, if the number of "split files" (whatever their names) increase even further, may I suggest they are moved into a subdir of their own, keeping just the main distribution and the README about the splits in the main dir? the "main distribution" will just be postgresql-server-.tar.gz ... postgresql-WTKS.tar.gz (with the kitchen sink) file that contained everything for those that really wanted to download "it all" ... That would be "postgresql-x.y.z.tar.gz", right? ;-) Nope, postgresql-x.y.z.tar.gz will just be the core distribution ...the WTKS will be the 'with the kitchen sink' meta distribution and would be in the subdir that you propose above ... in fact, I doubt that the WTKS will even be ready for the next release, as it will involve alot of work on the build system itself, I would think ... the 'cascading configure's could be interesting in itself ... Bottom line - make it easy for the *newbies*. Those of us who know exactly what we want will know where to look for it (say in a separate subdir). (or we'll just download the whole tarball anyway because that is *way* much more convenient... Speaking for myself there, of course.) Note that "the whole tar ball" will give you the core server and that is it ... the WTKS is a whole seperate project from what is being planned ... What is being worked on right now is effectively reducing things down to: postgresql-server (including libpq) postgresql- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
>> Commenting more broadly on the whole thread, I think that >more tarballs >> is a bad thing. I already get emails (both to webmaster and >privately) >> from people not understanding what to download - more files >will only >> make that worse. > >Going this route will eliminate alot of the confusion, and >probably result >in us not needing the seperate >postgresql--.tar.gz files >themselves, since there won't be anything left to put into the >side files >... I definitly agree with Dave taht this will confuse users - at least new users. Then again, they are already confused by what we have now. They can't really be expected to read the README file before they download it... As it is today, they download either one file (quite possibly the wrong one), or just the whole directory to be sure (getting a whole lot of duplicates). But. As long as there is still a "postgresql-x.y.z.tar.gz" file that has *everything that is contained in the split files*, we should be fine. Automated things like freebsd ports can pull the split files as needed, whereas users downloading "postgres" will get all they need. Actually, if the number of "split files" (whatever their names) increase even further, may I suggest they are moved into a subdir of their own, keeping just the main distribution and the README about the splits in the main dir? >Plus, also with what Josh has suggested, we'd also end up with a: > > postgresql-WTKS.tar.gz (with the kitchen sink) file >that contained >everything for those that really wanted to download "it all" ... That would be "postgresql-x.y.z.tar.gz", right? ;-) >So, there would be no confusion for what to download, since it >would all >be laid out for you ... you want a server with plperl, you >download the >server and the plperl tar file ... you already have a server, >but want to >add plpython, you download the plpython tar file ... You are assuming that the person downloading actually *knows* what he wants. This will frequently not be the case for somebody who is not already familiar with how the different parts of PostgreSQL interacts. Bottom line - make it easy for the *newbies*. Those of us who know exactly what we want will know where to look for it (say in a separate subdir). (or we'll just download the whole tarball anyway because that is *way* much more convenient... Speaking for myself there, of course.) //Magnus ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Thu, 5 May 2005, Joshua D. Drake wrote: dbsize.tar.gz btree_gist.tar.gz etc The end result wouldn't have enough in the *core* module to warrant a split-dist anymore, since all of what would be left would be what is required for a build ... I know some of this is symantic but I think it would be better to have: postgresql-WTKS-8.0.2.tar.gz postgresql-core-8.0.2.tar.gz postgresql-plphp postgresql-plperl that works too ... but I'd change -core to -server ... the only thing I have against is that the names could get very long: postgresql-fuzzystrmatch-8.0.2.tar.gz the postgresql part just seems redundant ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
dbsize.tar.gz btree_gist.tar.gz etc The end result wouldn't have enough in the *core* module to warrant a split-dist anymore, since all of what would be left would be what is required for a build ... I know some of this is symantic but I think it would be better to have: postgresql-WTKS-8.0.2.tar.gz postgresql-core-8.0.2.tar.gz postgresql-plphp postgresql-plperl etc... Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Thu, 5 May 2005, Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc G. Fournier Sent: 05 May 2005 21:08 To: Robert Treat Cc: Tom Lane; Josh Berkus; pgsql-hackers@postgresql.org Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement 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 I don't believe that's a good idea. Speaking from an ODBC pov, not only is the primary distribution for Windows, but the whole project is version independent of PostgreSQL and follows it's own release cycles entirely. odbc was just an example ... I'm not looking to include anything arbitrarily, as there will have to be some coordination done with the individual developers from at tagging perspective anyway ... Commenting more broadly on the whole thread, I think that more tarballs is a bad thing. I already get emails (both to webmaster and privately) from people not understanding what to download - more files will only make that worse. Going this route will eliminate alot of the confusion, and probably result in us not needing the seperate postgresql--.tar.gz files themselves, since there won't be anything left to put into the side files ... postgresql-opt would disappear and be replaced by: plperl.tar.gz plpython.tar.gz pltcl.tar.gz etc Josh has already proposed next step after PLs being the various contrib modules, so we'd have a: dbsize.tar.gz btree_gist.tar.gz etc The end result wouldn't have enough in the *core* module to warrant a split-dist anymore, since all of what would be left would be what is required for a build ... Plus, also with what Josh has suggested, we'd also end up with a: postgresql-WTKS.tar.gz (with the kitchen sink) file that contained everything for those that really wanted to download "it all" ... So, there would be no confusion for what to download, since it would all be laid out for you ... you want a server with plperl, you download the server and the plperl tar file ... you already have a server, but want to add plpython, you download the plpython tar file ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Marc > G. Fournier > Sent: 05 May 2005 21:08 > To: Robert Treat > Cc: Tom Lane; Josh Berkus; pgsql-hackers@postgresql.org > Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement > > > 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 I don't believe that's a good idea. Speaking from an ODBC pov, not only is the primary distribution for Windows, but the whole project is version independent of PostgreSQL and follows it's own release cycles entirely. Commenting more broadly on the whole thread, I think that more tarballs is a bad thing. I already get emails (both to webmaster and privately) from people not understanding what to download - more files will only make that worse. Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: 'kitchen sink' downloads (Was: Re: [pgsql-advocacy] [HACKERS] Increased company involvement)
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 BerkusConsultant josh@agliodbs.comwww.agliodbs.com Ph: 415-752-2500Fax: 415-752-2387 2166 Hayes Suite 200San Francisco, CA ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
'kitchen sink' downloads (Was: Re: [pgsql-advocacy] [HACKERS] Increased company involvement)
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Marc > G. Fournier > Sent: 05 May 2005 20:21 > To: Peter Eisentraut > Cc: Marc G. Fournier; Tom Lane; Josh Berkus; > pgsql-hackers@postgresql.org > Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement > > '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. ODBC releases are at http://www.postgresql.org/ftp/odbc/, or /pub/odbc in the FTP hierachy (and have been for years). You can't get much more visible than that!! Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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 (<[EMAIL PROTECTED]>) 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) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
"Marc G. Fournier" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Thu, 5 May 2005, Tom Lane wrote: Josh Berkus writes: Still sounds good. Do you think that this system could be extended to other add-ons in the future which are currently more complex builds? And allow us to out some of the wierder things in /contrib? The "system" already exists --- it's pgxs. We already have a report from Thomas Hallgren that pgxs works for building pljava, so I'm not too concerned about assuming it can be used for the other PLs. And I think we have already pgxs-ified all of contrib, though that's not the current standard method of building contrib. I have no problem with pushing out any part of contrib that doesn't seem tightly tied to the core server. I'm not entirely sure where to draw the line, but for instance I'd probably want to keep dblink where it is, since functions-returning-records are still in considerable flux. Can I suggest that we focus on PLs first and foremost, since that will allow us to get stuff like pl/PHP, pl/Java, pl/J(?), and pl/R in place, and then ramp up other stuff as time permits? Do we want to consider adding in a "mirror" of the JDBC/ODBC stuff in the same way? Based on the direction we are taking, I'm all for it .. the idea being that when beta starts, the JDBC folk (or ODBC, or ?) would submit a mega patch to be applied to the tree and tag'd in with the rest of it, and beta distribution copies built up ... development of the various drivers would remain on gborg/pgfoundry where they are now, all we'd have in our CVS would be 'the released version' ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Josh Berkus writes: > Still sounds good. Do you think that this system could be extended to other > add-ons in the future which are currently more complex builds? And allow us > to out some of the wierder things in /contrib? The "system" already exists --- it's pgxs. We already have a report from Thomas Hallgren that pgxs works for building pljava, so I'm not too concerned about assuming it can be used for the other PLs. And I think we have already pgxs-ified all of contrib, though that's not the current standard method of building contrib. I have no problem with pushing out any part of contrib that doesn't seem tightly tied to the core server. I'm not entirely sure where to draw the line, but for instance I'd probably want to keep dblink where it is, since functions-returning-records are still in considerable flux. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Thu, 5 May 2005, Tom Lane wrote: Josh Berkus writes: But packaging them as separately buildable tarballs that depend only on the installed core fileset (headers + pgxs) seems a fine idea. I really can't see doing this without a better (i.e. CPAN / emerge / ports - like ) build system.Mind you, I'd really like such a build system, but if we require users to manually download several separate tarballs and untar them in exactly the right spot in the source tree, we're adding a bunch of extra effort for both users and packagers. Uh, that's not exactly what is being proposed. It would be a separate tarball that you could untar wherever you felt like, because it would not depend on the core source tree at all --- only on the files installed by a previous build of the core. I think Marc just suggested having all the PLs in one such tarball, rather than one for each which is what I was envisioning. Nope, I should have shut up about this, actually ... all I was proposing was an easy way for me (and nobody else) to do simultaneious tagging and branching without having to check out multiple modules individually ... as I said, I should have shut up about it, since its not something anyone else would care about :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Thu, 5 May 2005, Tom Lane wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Josh Berkus writes: >> But packaging them as separately buildable tarballs that depend only >> on the installed core fileset (headers + pgxs) seems a fine idea. > I really can't see doing this without a better (i.e. CPAN / emerge / ports - > like ) build system.Mind you, I'd really like such a build system, but if > we require users to manually download several separate tarballs and untar > them in exactly the right spot in the source tree, we're adding a bunch of > extra effort for both users and packagers. Uh, that's not exactly what is being proposed. It would be a separate tarball that you could untar wherever you felt like, because it would not depend on the core source tree at all --- only on the files installed by a previous build of the core. I think Marc just suggested having all the PLs in one such tarball, rather than one for each which is what I was envisioning. That would probably fix the "too many things to download" issue. Offhand it doesn't seem like it makes the what-order-do-I-build-my-RPMs in problem any worse. It would complicate the license issue though. For ease of labeling you really want all the code in a given tarball to have the same license, and we couldn't expect to have that for all the PLs. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
"Marc G. Fournier" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Thu, 5 May 2005, Tom Lane wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
"Marc G. Fournier" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]) -- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Joe Conway <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [OT] Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On 5/4/05, Russell Smith <[EMAIL PROTECTED]> wrote: > On Wed, 4 May 2005 04:40 am, Tom Copeland wrote: > > On Tue, 2005-05-03 at 14:26 -0400, Mitch Pirtle wrote: > > > > Of course, Mitch is running the second largest GForge site on the planet > > (as far as I know) second only to https://helixcommunity.org/. > > Here's a list of them: > > > > http://gforge.org/docman/view.php/1/52/gforge-sites.html > > > Where does all the CPU/disk time go? Do we have any idea what are the > strained parts of the system? > > Is it the database? It is an even mix of apache/mod_php and postgresql. After looking around, I'm not that impressed with the state of the PHP code, and suspect that the data model may also be in great need of some TLC. Thinking about getting more involved in Gforge, to see if some of the glaring issues can be taken care of. -- Mitch ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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. Dave Tom Lane wrote: "Joshua D. Drake" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]) -- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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...) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Josh Berkus writes: >> Joe Conway's PL/R is in the back of my mind as well > Yeah, except PL/R has wierd build requirements (FORTRAN) and different > licensing (R is GPL). :-( [ shrug... ] All of the PLs except plpgsql require an outside language interpreter that has its own license and possibly problematic build requirements. We are not proposing including any of those things into our own distribution, only trying to figure out the best way to build PL modules that depend on both Postgres and these other projects. If we can see the right way to do this, I'd be in favor of pulling all of pltcl, plperl, and plpython out of the core distro. They are all sources of undesirable build dependencies. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
"Joshua D. Drake" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Tom Lane wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
"Marc G. Fournier" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Wed, 4 May 2005, Joshua D. Drake wrote: Tom Lane wrote: Bruce Momjian writes: My idea is that the second stage would just have them go to src/pl/plphp and type 'gmake install'. Absolutely not. It has to work as an independent package, not as something that expects to build inside an already-configured Postgres source tree. That means its own configure etc. Wait I am confused. Right now plPHP is setup to be a part of the source tree. It uses ./configure --with-php etc... So where are we going? plphp.tar.gz being seperately buildable from the core distribution, without the core distribution source files ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Tom Lane wrote: Bruce Momjian writes: My idea is that the second stage would just have them go to src/pl/plphp and type 'gmake install'. Absolutely not. It has to work as an independent package, not as something that expects to build inside an already-configured Postgres source tree. That means its own configure etc. Wait I am confused. Right now plPHP is setup to be a part of the source tree. It uses ./configure --with-php etc... So where are we going? Sincerely, Joshua D. Drake Basically, we can keep the files in our CVS for ease of maintenance, but that is not going to show up at all in terms of what is shipped in the two tarballs --- they will be independent products. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Bruce Momjian writes: > My idea is that the second stage would just have them go to src/pl/plphp > and type 'gmake install'. Absolutely not. It has to work as an independent package, not as something that expects to build inside an already-configured Postgres source tree. That means its own configure etc. Basically, we can keep the files in our CVS for ease of maintenance, but that is not going to show up at all in terms of what is shipped in the two tarballs --- they will be independent products. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Monday 02 May 2005 15:12, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> 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
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [OT] Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Wed, 4 May 2005 04:40 am, Tom Copeland wrote: > On Tue, 2005-05-03 at 14:26 -0400, Mitch Pirtle wrote: > > If you guys are planning on running Gforge, then you better make 'box' > > plural. > > > > I'm running MamboForge.net, and the poor thing is getting beat into > > the cold hard earth every day. We (Mambo) should really have two > > servers, at least to dedicate hardware to the database. Most of the > > servers in that class are dual Xeons as well - just as an indicator of > > what you are getting yourselves into ;-) > > Of course, Mitch is running the second largest GForge site on the planet > (as far as I know) second only to https://helixcommunity.org/. > Here's a list of them: > > http://gforge.org/docman/view.php/1/52/gforge-sites.html > Where does all the CPU/disk time go? Do we have any idea what are the strained parts of the system? Is it the database? Regards Russell Smith. > Yours, > > Tom Copeland > > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Marc > G. Fournier > Sent: 03 May 2005 19:09 > To: Joshua D. Drake > Cc: Marc G. Fournier; Tom Lane; Peter Eisentraut; Bruce > Momjian; PostgreSQL-development > Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement > > and I believe there are still alot of places in > Europe (or is/was > it just GB?) that pay per byte for their bandwidth ... Not pay-per-byte as such (in .uk), but many people do use cheap lines that have monthly caps on them that they then pay top-up charges for overusage on. Even one of our business lines is setup that way. That said though, the worst of those caps I've ever seen is 1GB/month, which is a heck of a lot of copies of PostgreSQL. /D ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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-.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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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
[OT] Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tue, 2005-05-03 at 14:26 -0400, Mitch Pirtle wrote: > If you guys are planning on running Gforge, then you better make 'box' plural. > > I'm running MamboForge.net, and the poor thing is getting beat into > the cold hard earth every day. We (Mambo) should really have two > servers, at least to dedicate hardware to the database. Most of the > servers in that class are dual Xeons as well - just as an indicator of > what you are getting yourselves into ;-) Of course, Mitch is running the second largest GForge site on the planet (as far as I know) second only to https://helixcommunity.org/. Here's a list of them: http://gforge.org/docman/view.php/1/52/gforge-sites.html Yours, Tom Copeland ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tuesday 03 May 2005 13:51, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> 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
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED]) -- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] 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/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
* Peter Eisentraut ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
* Marc G. Fournier ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
* Marc G. Fournier ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
* Tom Lane ([EMAIL PROTECTED]) wrote: > Robert Treat <[EMAIL PROTECTED]> 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 signature.asc Description: Digital signature
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
* Robert Treat ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Mitch Pirtle wrote: On 4/30/05, Jim C. Nasby <[EMAIL PROTECTED]> wrote: If money's not an issue anymore, can we get a bigger box to host pgfoundry on then? :) If you guys are planning on running Gforge, then you better make 'box' plural. Well we already run it :) For pgFoundry and you are correct it seems to be a bit of a pig. Our new machines should handle it better though. 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/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
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
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
