Thread: Three weeks left until feature freeze
There are roughly three weeks left until the feature freeze on August 1. If people are working on items, they should be announced before August 1, and the patches submitted by August 1. If the patch is large, it should be discussed now and an intermediate patch posted to the lists soon. FYI, we don't have many major features ready for 8.2. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
I'd like to submit PL/Java into core for 8.2 if possible. Personally, I see the following action items to make it happen: 1. A "hackers" discussion to resolve any issues with the submission. Provided that #1 has a positive outcome: 2. The PL/Java CVS must be moved from gborg and become part of the PostgreSQL CVS (can this be done with version history intact?). 3. The regression tests need some work in order to fit in with the build farm. 4. Documentation must be ripped from the PL/Java Wiki and transformed into the format used by PostgreSQL. 5. I'll need committer rights to the PL/Java part in order to maintain it. 6. The pljava-dev mailing list, currently at gborg, must (perhaps) be moved also. An alternative is to remove it and instead refer to jdbc, general, and hackers. Given guidance, I'll do the steps #3 and #4. External dependencies: Platforms where PL/Java is ported must either support GCJ 4.0 or higher or have a Java Runtime Environment 1.4.2 or higher installed. Regards, Thomas Hallgren Bruce Momjian wrote: > There are roughly three weeks left until the feature freeze on August 1. > If people are working on items, they should be announced before August > 1, and the patches submitted by August 1. If the patch is large, it > should be discussed now and an intermediate patch posted to the lists > soon. > > FYI, we don't have many major features ready for 8.2. > > -- > Bruce Momjian bruce@momjian.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings >
Thomas Hallgren <thomas@tada.se> writes:
> I'd like to submit PL/Java into core for 8.2 if possible. Personally, I see the following
> action items to make it happen:
What about licensing issues? Does PL/Java work with any entirely-open-source
JVMs? If not, what is the legal situation for distributing PG+PL/Java?
I'm also a bit concerned about size. By my count, lines of source code:
plpgsql 19890
plperl 4902
plpython 4163
pltcl 4498
pljava 1.3.0 38711
IOW pljava is (already) bigger than the other four PLs put together.
I'm inclined to think that pljava is best off staying as a separate
project.
regards, tom lane
Tom, Tom Lane wrote: > IOW pljava is (already) bigger than the other four PLs put together. > > I'm inclined to think that pljava is best off staying as a separate > project. I was very confused some recent PL/Java versions can't be compiled because of PostgreSQL internal changes. If people think pl/java is important for PostgreSQL, pl/java should be included in PG core tree, and should have its regression tests. I think PL should be integrated with core tightly. Thanks. -- NAGAYASU Satoshi <nagayasus@nttdata.co.jp> Phone: +81-3-3523-8122
Thomas Hallgren wrote: > > 5. I'll need committer rights to the PL/Java part in order to maintain > it. Does our CVS setup cater for seggregated rights like this? Or would that be done on a trust basis? cheers andrew
Tom, > What about licensing issues? Does PL/Java work with any entirely-open-source > JVMs? If not, what is the legal situation for distributing PG+PL/Java? Actually, Sun has re-licensed the JRE to make it OSS-compatible (it's now available for Debian, for example) They're doing a Java licensing session at OSCON if you have any specific questions, or I can ping the Java Licensing Guru directly. But even if other JRE's aren't supported, licensing shouldn't be an obstacle. > > I'm also a bit concerned about size. By my count, lines of source code: > > plpgsql 19890 > plperl 4902 > plpython 4163 > pltcl 4498 > pljava 1.3.0 38711 > > IOW pljava is (already) bigger than the other four PLs put together. That is odd. Thomas? > > I'm inclined to think that pljava is best off staying as a separate > project. I disagree. One of the things I'm asked by every single tech market analyst, after replication & clustering, is whether we have support for procedural Java. So it's something large-scale users want. If PL/Tcl belongs in the back end, then so does PL/Java. --Josh Berkus
On Tue, Jul 11, 2006 at 11:21:54PM +0900, Satoshi Nagayasu wrote: > Tom, > > Tom Lane wrote: > > IOW pljava is (already) bigger than the other four PLs put > > together. > > > > I'm inclined to think that pljava is best off staying as a > > separate project. > > I was very confused some recent PL/Java versions can't be compiled > because of PostgreSQL internal changes. > > If people think pl/java is important for PostgreSQL, pl/java should > be included in PG core tree, and should have its regression tests. > > I think PL should be integrated with core tightly. It's good to integrate things with the core as needed. What plans do we have to integrate PL/J? Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
Andrew Dunstan wrote: > Thomas Hallgren wrote: > > > > 5. I'll need committer rights to the PL/Java part in order to maintain > > it. > > > Does our CVS setup cater for seggregated rights like this? Or would that > be done on a trust basis? Trust. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of > Andrew Dunstan > Sent: 11 July 2006 15:27 > To: Thomas Hallgren > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Three weeks left until feature freeze > > Thomas Hallgren wrote: > > > > 5. I'll need committer rights to the PL/Java part in order > to maintain > > it. > > > Does our CVS setup cater for seggregated rights like this? Or > would that > be done on a trust basis? No, I don't believe you can do this with CVS at all. We'd need something like SVN/WebDAV to be able to grant write access just to specific parts of the tree to different people. Regards, Dave.
Bruce Momjian wrote: > Andrew Dunstan wrote: > > Thomas Hallgren wrote: > > > > > > 5. I'll need committer rights to the PL/Java part in order to maintain > > > it. > > > > > > Does our CVS setup cater for seggregated rights like this? Or would that > > be done on a trust basis? > > Trust. And pgsql-committers archives ;-) -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
> > Does our CVS setup cater for seggregated rights like this? Or > > would that > > be done on a trust basis? > > No, I don't believe you can do this with CVS at all. We'd need something > like SVN/WebDAV to be able to grant write access just to specific parts > of the tree to different people. It is possible using CVS, by carefully managing file system permissions and assigning different permissions to the OS users of the different committers. I guess it's also possible using commit scripts... but I don't think it worths the effort as long as there is a regular backup of the CVS tree... Cheers, Csaba.
Josh Berkus wrote: > Tom, > >> What about licensing issues? Does PL/Java work with any >> entirely-open-source >> JVMs? If not, what is the legal situation for distributing PG+PL/Java? > > Actually, Sun has re-licensed the JRE to make it OSS-compatible (it's > now available for Debian, for example) They're doing a Java licensing > session at OSCON if you have any specific questions, or I can ping > the Java Licensing Guru directly. But even if other JRE's aren't > supported, licensing shouldn't be an obstacle. > I don't see any license issue at all regardless. PL/Java is satisfied with GCJ 4.0 or higher and compiling with that doesn't affect the binary more then using gcc does. No JVM is required when using GCJ. >> >> I'm also a bit concerned about size. By my count, lines of source code: >> >> plpgsql 19890 >> plperl 4902 >> plpython 4163 >> pltcl 4498 >> pljava 1.3.0 38711 >> >> IOW pljava is (already) bigger than the other four PLs put together. > > That is odd. Thomas? > It's not that odd really: 1. the mapping is strongly typed, i.e. each scalar type in PostgreSQL has a set of functions that maps it to the correct primitive in Java (int4 is a java int, double precision is a double etc.). PL/Java will resort to string coercion only when no other option is left. 2. a type mapping is provided for *all* types. Scalar, composite, pseudo, array types, and result sets. 3. new Java mappings can be created on the fly. Both for scalar and composite types. 4. you can create new scalar types in PostgreSQL that uses IO functions written in Java. 5. the Java code contains it's own API documentation (standard java-doc comments on classes and methods). 6. the code is written to conform to standard interfaces such as the JDBC interfaces (from a #lines perspective, perhaps not always the most optimal way of doing it but it does bring a bunch of other advantages). 7. extensive error handling is included that allow try/catch semantics when checkpoints are used. 8. extreme measures has been taken to ensure that the backend is never exposed to more then one thread at a time. ... (from the top of my head, there are probably more reasons) IMHO, this is yet another reason to actually include it in core. I'm not an expert on the other PL's but my guess is that PL/Java is far more sensitive to API changes in the backend core. Regards, Thomas Hallgren
Josh Berkus wrote: > >I'm inclined to think that pljava is best off staying as a separate > >project. > > I disagree. One of the things I'm asked by every single tech market > analyst, after replication & clustering, is whether we have support for > procedural Java. So it's something large-scale users want. If PL/Tcl > belongs in the back end, then so does PL/Java. We've discussed this before, regarding PL/php IIRC. The conclusions the last time around, as far as I remember, was that we wanted the PLs to be in the same CVS repo, but able to be compiled separately from the whole source tree. So we could sort of rip PL/Perl et al from the actual backend code, leaving only enough infrastructure to be able to build them easily (PGXS plus a bunch of stuff, I imagine). PL modules would follow the backend branches so that there would be no need for pesky #ifdef PGSQL_VERSION_THIS_OR_THAT stuff; but they would actually be separate. The main motivation was that when somebody wants to change an interface in the backend that's used by PLs, it's useful to change all of them at the same time instead of waiting until release time comes and the things does not compile anymore and nobody remembers when or where they were broken. I think this would also allow PL/R to be included as well despite the license, because while it would be in the same repo and editable together with the backend, it would continue to be a separate project and thus not contaminate the backend with GPL stuff. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
* Josh Berkus (josh@agliodbs.com) wrote:
> Actually, Sun has re-licensed the JRE to make it OSS-compatible (it's
> now available for Debian, for example) They're doing a Java licensing
> session at OSCON if you have any specific questions, or I can ping the
> Java Licensing Guru directly. But even if other JRE's aren't supported,
> licensing shouldn't be an obstacle.
Uhh.. Let's not go overboard here on exactly what Debian has done with
Sun's JVM. Technically, Sun's JVM is *not* part of Debian. The license
is (and even this is hotly debated...) acceptable enough for Debian's
ftp-masters to allow the Sun JVM to be distributed off Debian servers as
part of the 'non-free' archive. This *certainly* doesn't make it
OSS-compatible by any stretch (it isn't) and it's not acceptable for
inclusion in Debian proper.
I'm actually rather upset to see Sun making such blatently incorrect
statements. Josh, I truely hope that you weren't actually involved in
the Sun JVM-in-Debian work and so were unaware of the very important
distinction between "Distributed by Debian" and "in Debian/main".
Thanks,
Stephen
David, > It's good to integrate things with the core as needed. What plans do > we have to integrate PL/J? None, if the PL/J team doesn't speak up. So far I have yet to see a request for PL/J or even a release notice. --Josh
Snowman, > Uhh.. Let's not go overboard here on exactly what Debian has done with > Sun's JVM. Technically, Sun's JVM is *not* part of Debian. The license > is (and even this is hotly debated...) acceptable enough for Debian's > ftp-masters to allow the Sun JVM to be distributed off Debian servers as > part of the 'non-free' archive. This *certainly* doesn't make it > OSS-compatible by any stretch (it isn't) and it's not acceptable for > inclusion in Debian proper. I think I can tell which side of the debate you were on. > I'm actually rather upset to see Sun making such blatently incorrect > statements. Josh, I truely hope that you weren't actually involved in > the Sun JVM-in-Debian work and so were unaware of the very important > distinction between "Distributed by Debian" and "in Debian/main". Keep your pants on, geez. I'm actually rather appalled that you could get so unjustifiably bent out of shape at me *after* we met. Goes to show you that not everything is improved by personal acquaintance. Let's get some stuff clear: 1) I do not speak for Sun execept on specific occasions arranged by Sun PR. Not ever. 2) If you re-read my message, it says: ... (it's now available for Debian, for example) ... not ANYTHING about main or distributed or non-free or whatever. So, I think you owe me an apology. --Josh
Andrew Dunstan <andrew@dunslane.net> writes:
> Thomas Hallgren wrote:
>> 5. I'll need committer rights to the PL/Java part in order to maintain
>> it.
> Does our CVS setup cater for seggregated rights like this? Or would that
> be done on a trust basis?
No, and yes. However, I don't have a problem with giving Thomas
committer access --- I'm just dubious about having PL/Java in the
core distro at all.
regards, tom lane
Stephen, > You seemed to use the recent change in status of Sun's JVM (at least in > part with regard to Debian...) as justification of your statement that > it's OSS-compatible.. Are you going to be at OSCON? Sun's hosting a BOF to discuss exactly this issue. --Josh
On Tuesday 11 July 2006 13:49, Andrew Dunstan wrote: > Joshua D. Drake wrote: > >... and before you say it, No. I do not wear a tie. > > Maybe you need to ... ;-) > /me bows before the gods who thoust commit. > > cheers > > andrew -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: >... and before you say it, No. I do not wear a tie. > > > Maybe you need to ... ;-) cheers andrew
* Josh Berkus (josh@agliodbs.com) wrote:
> I think I can tell which side of the debate you were on.
The debate was regarding Sun's JVM being distributed by Debian at all...
There wasn't any debate regarding it's free vs. non-free status so far
as I'm aware. I don't believe there was ever any intention to include
Sun's JVM in Debian/main with it's current license. If you meant
something other than free/non-free by 'OSS-compatible' then you might
have wanted to make that clear since generally that refers to the OSI
Open Source Definition (and/or the DFSG, they're pretty similar tho).
I've not heard 'OSS-compatible' used to refer to 'can run under Linux'
or 'can run on Debian' before. That'd include things like Oracle.
> >I'm actually rather upset to see Sun making such blatently incorrect
> >statements. Josh, I truely hope that you weren't actually involved in
> >the Sun JVM-in-Debian work and so were unaware of the very important
> >distinction between "Distributed by Debian" and "in Debian/main".
>
> Keep your pants on, geez. I'm actually rather appalled that you could
> get so unjustifiably bent out of shape at me *after* we met. Goes to
> show you that not everything is improved by personal acquaintance.
Actually, I felt that I pretty clearly gave you the benefit of the
doubt... For many people it's an unfortunate and pretty likely
assumption based on things written on /., etc. It wasn't an attack on
you but rather the frustrated realization that the concerns of many in
Debian regarding Sun's JVM inclusion in non-free may have been justified.
> 2) If you re-read my message, it says:
> ... (it's now available for Debian, for example) ...
> not ANYTHING about main or distributed or non-free or whatever.
If you hadn't intended to refer to Debian's inclusion of the Sun JVM in
non-free then I'm rather confused since there has been a trivial-to-use
package available in non-free for a long time to download the Sun JVM
from Sun and create debs to install it with. So, it's been available
*for* Debian for a long time, but was only recently put into non-free..
It was also available prior to that, though a pain to install..
You seemed to use the recent change in status of Sun's JVM (at least in
part with regard to Debian...) as justification of your statement that
it's OSS-compatible..
That's exactly the misrepresentation which I was addressing.
> So, I think you owe me an apology.
I apologize for being harsher than I should have.
Thanks,
Stephen
Hi Hannu, Hannu Krosing wrote: > Maybe this functionality could be lifted out of PL/Java and made > available to all PL-s ? > > At least at some API level. > > I think that what could be shared are the ideas and the semantics. The API's that the backend currently expose will give you what's needed to do the specialized implementations. The actual PL mappings are all different because their respective "executor" is different. Some languages are typed, others are not. Some languages support classes and objects, others don't. Other, more esoteric details like the use of a garbage collector or traditional alloc/free semantics also affects the actual implementation. I'm afraid there's not much in the PL/Java type system that could be generalized and shared. Perhaps if we had other languages with very similar capabilities (like C# for instance) but even then I have some doubts. The good news in my opinion is that if PL/Java would make it to the core it could make a good reference implementation for other equally advanced language mappings. Regards, Thomas Hallgren
On Tuesday 11 July 2006 09:59, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > > Thomas Hallgren wrote: > >> 5. I'll need committer rights to the PL/Java part in order to maintain > >> it. > > > > Does our CVS setup cater for seggregated rights like this? Or would that > > be done on a trust basis? > > No, and yes. However, I don't have a problem with giving Thomas > committer access --- I'm just dubious about having PL/Java in the > core distro at all. Personally I would like to see in core, but it is not from a technical perspective. It is purely from a marketing perspective (doubt that carries much weight here ;)). Having pl/Java helps PostgreSQL in the minds of all those tie wearing decision making freaks... and before you say it, No. I do not wear a tie. Sincerely, Joshua D. Drake > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Tue, 11 Jul 2006, Josh Berkus wrote: > I disagree. One of the things I'm asked by every single tech market > analyst, after replication & clustering, is whether we have support for > procedural Java. So it's something large-scale users want. If PL/Tcl > belongs in the back end, then so does PL/Java. There should be a Procedural Language section on pgfoundry for all of the PLs, IMHO, and a README in contrib within core that points to it (README.procedural_languages, if nothing else) ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Ühel kenal päeval, T, 2006-07-11 kell 17:34, kirjutas Thomas Hallgren: > Josh Berkus wrote: > > Tom, > > > >> IOW pljava is (already) bigger than the other four PLs put together. > > > > That is odd. Thomas? > > > It's not that odd really: > > 1. the mapping is strongly typed, i.e. each scalar type in PostgreSQL > has a set of functions that maps it to the correct primitive in Java > (int4 is a java int, double precision is a double etc.). PL/Java will > resort to string coercion only when no other option is left. > 2. a type mapping is provided for *all* types. Scalar, composite, > pseudo, array types, and result sets. > 3. new Java mappings can be created on the fly. Both for scalar and > composite types. > 4. you can create new scalar types in PostgreSQL that uses IO functions > written in Java. Maybe this functionality could be lifted out of PL/Java and made available to all PL-s ? At least at some API level. -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com
> No, I don't believe you can do this with CVS at all. We'd need something > like SVN/WebDAV to be able to grant write access just to specific parts > of the tree to different people. You just use an on-commit script like cvsacl.
> I'm afraid there's not much in the PL/Java type system that could be > generalized and shared. Perhaps if we had other languages with very > similar capabilities (like C# for instance) but even then I have some > doubts. The good news in my opinion is that if PL/Java would make it to > the core it could make a good reference implementation for other equally > advanced language mappings. What is the actual concern with having PL/Java in core, versus say PL/Perl? Sincerely, Joshua D. Drake > > Regards, > Thomas Hallgren > > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Marc G. Fournier wrote: > On Tue, 11 Jul 2006, Josh Berkus wrote: > > >I disagree. One of the things I'm asked by every single tech market > >analyst, after replication & clustering, is whether we have support for > >procedural Java. So it's something large-scale users want. If PL/Tcl > >belongs in the back end, then so does PL/Java. > > There should be a Procedural Language section on pgfoundry for all of the > PLs, IMHO, and a README in contrib within core that points to it > (README.procedural_languages, if nothing else) ... This is not a smart idea, because it will mean API changes in the backend cannot fix the PLs right away (and also because it's harder to track each core branch, something which having the actual language in the same repo makes trivial AFAIK). I don't understand why you keep proposing this after having the idea shot down over and over. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
> There should be a Procedural Language section on pgfoundry for all of the > PLs, IMHO, and a README in contrib within core that points to it > (README.procedural_languages, if nothing else) ... I thought that the general consensus was that only plpgsql ought to be in core, the rest should be independent projects. It would be nice to have an easy way to retrieve and install the desired PL's but that's more of a packaging issue. -- Med venlig hilsen Kaare Rasmussen, Jasonic Jasonic Telefon: +45 3816 2582 Nordre Fasanvej 12 2000 Frederiksberg Email: kaare@jasonic.dk
Absolutely PL/J should be considered in the same light as PL/Java. Consider this a request for PL/J to be included in the core. Dave On 11-Jul-06, at 12:50 PM, Josh Berkus wrote: > David, > >> It's good to integrate things with the core as needed. What plans do >> we have to integrate PL/J? > > None, if the PL/J team doesn't speak up. So far I have yet to see > a request for PL/J or even a release notice. > > --Josh > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings >
Marc G. Fournier wrote: > > There should be a Procedural Language section on pgfoundry for all of > the PLs, IMHO, and a README in contrib within core that points to it > (README.procedural_languages, if nothing else) ... > This was a bad idea last time it was proposed and is still a bad idea for the same reasons that caused it to be rejected then. cheers andrew
Kaare Rasmussen wrote: >> There should be a Procedural Language section on pgfoundry for all of the >> PLs, IMHO, and a README in contrib within core that points to it >> (README.procedural_languages, if nothing else) ... >> > > I thought that the general consensus was that only plpgsql ought to be in > core, the rest should be independent projects. > > Quite the contrary, if anything. cheers andrew
Hi Dave, Sorry I missed you at the Summit. I would've liked to discuss PL/J versus PL/Java with you. What is the status of PL/J? I haven't seen much activity there over the last 10 months. Does it run on Windows yet? Are you planning a first release anytime soon? Do you have any active users? Does the project still have over 40 dependencies to other components? The last time I looked (August last year) a beta-0.1.1 was planned. I didn't manage to built it and it didn't seem anywhere close production readiness. Perhaps it's no surprise that I disagree when you say PL/J could be considered in the same light as PL/Java. Then again, I'm fairly biased ;-) Regards, Thomas Hallgren Dave Cramer wrote: > Absolutely PL/J should be considered in the same light as PL/Java. > > Consider this a request for PL/J to be included in the core. > > Dave > On 11-Jul-06, at 12:50 PM, Josh Berkus wrote: > >> David, >> >>> It's good to integrate things with the core as needed. What plans do >>> we have to integrate PL/J? >> >> None, if the PL/J team doesn't speak up. So far I have yet to see a >> request for PL/J or even a release notice. >> >> --Josh >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 5: don't forget to increase your free space map settings >> >
Am Dienstag, 11. Juli 2006 17:40 schrieb Alvaro Herrera: > We've discussed this before, regarding PL/php IIRC. The conclusions the > last time around, as far as I remember, was that we wanted the PLs to be > in the same CVS repo, but able to be compiled separately from the whole > source tree. That was precisely what I recall. But if we make them separate CVS modules, they would not have the same branch structure, or would they? -- Peter Eisentraut http://developer.postgresql.org/~petere/
Ühel kenal päeval, K, 2006-07-12 kell 09:49, kirjutas Kaare Rasmussen: > > There should be a Procedural Language section on pgfoundry for all of the > > PLs, IMHO, and a README in contrib within core that points to it > > (README.procedural_languages, if nothing else) ... > > I thought that the general consensus was that only plpgsql ought to be in > core, the rest should be independent projects. That would be doable if we had a stable language API. As i understand it, we still dont. And even more - most of the changes to API come frome the needs of those (new) languages > It would be nice to have an easy way to retrieve and install the desired PL's > but that's more of a packaging issue. > -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com
Hannu Krosing wrote: > Ühel kenal päeval, K, 2006-07-12 kell 09:49, kirjutas Kaare Rasmussen: > >>> There should be a Procedural Language section on pgfoundry for all of the >>> PLs, IMHO, and a README in contrib within core that points to it >>> (README.procedural_languages, if nothing else) ... >>> >> I thought that the general consensus was that only plpgsql ought to be in >> core, the rest should be independent projects. >> > > That would be doable if we had a stable language API. > > As i understand it, we still dont. And even more - most of the changes > to API come frome the needs of those (new) languages > > There is in effect no API at all, other than what is available to all backend modules. If someone wants to create an API which will be both sufficiently stable and sufficiently complete to meet the needs of the various PLs (especially, as Hannu rightly observes, any new PLs that come along) then we can revisit this question. Until then I suggest that it is at best premature. I am not even sure such a thing is actually possible. Also there is this: speaking as someone who actually does some work in this area, I very much appreciate having the eagle eyes of people like Tom, Neil and Joe on what's going on, and keeping things on the straight and narrow. I at least would feel lots less comfortable about maintaining things without such help. The Postgres hacker community is small. I am not sure there is an adequate pool of people who will maintain the momentum of each sub-project that we might choose to orphan. If we had thousands of eager code cutters it might be different, but we don't, really. cheers andrew
On Wed, Jul 12, 2006 at 07:29:52AM -0700, Joshua D. Drake wrote: > On Wednesday 12 July 2006 04:15, Dave Cramer wrote: > > Absolutely PL/J should be considered in the same light as PL/Java. > > > > Consider this a request for PL/J to be included in the core. > > Frankly I don't care which one is used, as long as the one (and ONLY one) that > is included is the most mature and stable. Are they mutually exclusive? I can imagine, at least for development purposes, that someone might want to install both. Cheers, D > > Sincerely, > > Joshua D. Drake > > > > > Dave > > > > On 11-Jul-06, at 12:50 PM, Josh Berkus wrote: > > > David, > > > > > >> It's good to integrate things with the core as needed. What plans do > > >> we have to integrate PL/J? > > > > > > None, if the PL/J team doesn't speak up. So far I have yet to see > > > a request for PL/J or even a release notice. > > > > > > --Josh > > > > > > ---------------------------(end of > > > broadcast)--------------------------- > > > TIP 5: don't forget to increase your free space map settings > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 6: explain analyze is your friend > > -- > === The PostgreSQL Company: Command Prompt, Inc. === > Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 > Providing the most comprehensive PostgreSQL solutions since 1997 > http://www.commandprompt.com/ > -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
On Wednesday 12 July 2006 04:15, Dave Cramer wrote: > Absolutely PL/J should be considered in the same light as PL/Java. > > Consider this a request for PL/J to be included in the core. Frankly I don't care which one is used, as long as the one (and ONLY one) that is included is the most mature and stable. Sincerely, Joshua D. Drake > > Dave > > On 11-Jul-06, at 12:50 PM, Josh Berkus wrote: > > David, > > > >> It's good to integrate things with the core as needed. What plans do > >> we have to integrate PL/J? > > > > None, if the PL/J team doesn't speak up. So far I have yet to see > > a request for PL/J or even a release notice. > > > > --Josh > > > > ---------------------------(end of > > broadcast)--------------------------- > > TIP 5: don't forget to increase your free space map settings > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On 7/12/06, David Fetter <david@fetter.org> wrote: > Are they mutually exclusive? I can imagine, at least for development > purposes, that someone might want to install both. I believe both can be installed and running at the same time. I don't really think anyone would want to run both, but that's just my opinion. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
Andrew Dunstan wrote: > There is in effect no API at all, other than what is available to all > backend modules. If someone wants to create an API which will be both > sufficiently stable and sufficiently complete to meet the needs of the > various PLs (especially, as Hannu rightly observes, any new PLs that > come along) then we can revisit this question. Until then I suggest > that it is at best premature. I am not even sure such a thing is > actually possible. > I concur with this. The needs for a module like PL/Java is very different then the needs of PL/Perl so let's get some more PL's in before we do a refactoring effort to create common API's. Personally, I'm not sure what would be included. The call handler API's together with the SPI API's are in essence what you need. The rest is fairly specialized anyway. > Also there is this: speaking as someone who actually does some work in > this area, I very much appreciate having the eagle eyes of people like > Tom, Neil and Joe on what's going on, and keeping things on the straight > and narrow. I at least would feel lots less comfortable about > maintaining things without such help. > This is partly why I'd like to get PL/Java included. Not that I expect any of them to devote resources to PL/Java but I think that they, from time to time, will visit the code. If not for anything else then to see why some other change caused build failures. It's always easier to have discussions around code that you know they all have on disk. > The Postgres hacker community is small. I am not sure there is an > adequate pool of people who will maintain the momentum of each > sub-project that we might choose to orphan. If we had thousands of eager > code cutters it might be different, but we don't, really. > As the project grows for various reasons, the number of hackers in the community will grow as well. PL/Java for instance, does not come without resources :-) Regards, Thomas Hallgren
On 7/12/06, Thomas Hallgren <thomas@tada.se> wrote: > it didn't seem anywhere close production readiness. > > Perhaps it's no surprise that I disagree when you say PL/J could be > considered in the same light as PL/Java. Having used both systems, I have to agree with Thomas; PL/Java is far ahead of PL/J in terms of production readiness. Rather than argue the differences between the architectures... I think it should be looked at on a pro/con basis. Many people have asked for procedural Java and generally pass over PostgreSQL because they don't know about PL/Java or PL/J. In my opinion, having a Java PL included in the core would be ideal. PL/Java seems to be the only Java PL under consistent development and maintenance, so I don't see it as something that would fall on the shoulders of all other maintainers. Just my 2 cents :) -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On Wed, Jul 12, 2006 at 10:14:53AM -0400, Andrew Dunstan wrote: > Hannu Krosing wrote: > >Ühel kenal päeval, K, 2006-07-12 kell 09:49, kirjutas Kaare Rasmussen: > > > >>>There should be a Procedural Language section on pgfoundry for all of the > >>>PLs, IMHO, and a README in contrib within core that points to it > >>>(README.procedural_languages, if nothing else) ... > >>> > >>I thought that the general consensus was that only plpgsql ought to be in > >>core, the rest should be independent projects. > >> > > > >That would be doable if we had a stable language API. > > > >As i understand it, we still dont. And even more - most of the changes > >to API come frome the needs of those (new) languages > > > > > > There is in effect no API at all, other than what is available to all > backend modules. If someone wants to create an API which will be both > sufficiently stable and sufficiently complete to meet the needs of the > various PLs (especially, as Hannu rightly observes, any new PLs that > come along) then we can revisit this question. Until then I suggest > that it is at best premature. I am not even sure such a thing is > actually possible. > > Also there is this: speaking as someone who actually does some work in > this area, I very much appreciate having the eagle eyes of people like > Tom, Neil and Joe on what's going on, and keeping things on the straight > and narrow. I at least would feel lots less comfortable about > maintaining things without such help. If I've caught the right threads... Informix IUS and Illustra had a language manager module which facilitated function resolution and argument marshalling ala SQL and then made the calls to each language in the same API/function call format. Usually I do not like added layers, however, this layer could and should be used to deal with function resolution, type coercion, domains, etc, which is the SQL side. The language itself would have predefined ways of getting arguments and returning data. I'm not sure if this approach would work with the bonus extras on plpgsql, but it should. If anyone wants to pursue this area, please include me on the discussion and I can try to provide information regarding the other implementation. --elein > > The Postgres hacker community is small. I am not sure there is an > adequate pool of people who will maintain the momentum of each > sub-project that we might choose to orphan. If we had thousands of eager > code cutters it might be different, but we don't, really. > > cheers > > andrew > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
> I concur with this. The needs for a module like PL/Java is very different > then the needs of PL/Perl so let's get some more PL's in before we do a > refactoring effort to create common API's. Personally, I'm not sure what > would be included. The call handler API's together with the SPI API's are > in essence what you need. The rest is fairly specialized anyway. Well I know it isn't an API per say, but one interesting tid bit as an example is that PLphp does not need the PostgreSQL source to compile. It only needs pgxs and the relevant headers etc... Perhaps that is one way to go... All PLs use pgxs? > As the project grows for various reasons, the number of hackers in the > community will grow as well. PL/Java for instance, does not come without > resources :-) We have already grown for hackers quite a bit this year as they mature I think we will see even more patch review eyes and such... Soon. Sincerely, Joshua D. Drake > > Regards, > Thomas Hallgren > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: > > Well I know it isn't an API per say, but one interesting tid bit as an example > is that PLphp does not need the PostgreSQL source to compile. It only needs > pgxs and the relevant headers etc... > > Perhaps that is one way to go... All PLs use pgxs? > > PL/Java does. No source needed. So yes, there's already a fairly good API that assists in the module build process. It does however still include all header files needed by the backend and thus, leaves the backend wide open (in a matter of speech). If a refactoring effort was to start later on, that would be a good place to start. I.e. divide headers into the ones available for external modules and the ones for internal backend use only. Regards, Thomas Hallgren
"Jonah H. Harris" <jonah.harris@gmail.com> writes:
> On 7/12/06, David Fetter <david@fetter.org> wrote:
>> Are they mutually exclusive? I can imagine, at least for development
>> purposes, that someone might want to install both.
> I believe both can be installed and running at the same time. I don't
> really think anyone would want to run both, but that's just my
> opinion.
On what grounds do you not think that? PL/J uses an external JVM,
PL/Java one that is running in the backend process. (Or maybe it was
the other way 'round, I'm too tired to remember tonight.) That's a
really fundamental difference that makes them suited for very different
applications; not to mention the resulting different licensing scenarios.
The points that have been made in this thread about PL/J not being
actively maintained are important, but other than that objection,
I can see no reason that PL/J wouldn't have an equal claim to inclusion
in core. Perhaps more, because it gives us an extra layer of insulation
from JVM licensing questions.
regards, tom lane
On 12-Jul-06, at 10:44 PM, Tom Lane wrote: > "Jonah H. Harris" <jonah.harris@gmail.com> writes: >> On 7/12/06, David Fetter <david@fetter.org> wrote: >>> Are they mutually exclusive? I can imagine, at least for >>> development >>> purposes, that someone might want to install both. > >> I believe both can be installed and running at the same time. I >> don't >> really think anyone would want to run both, but that's just my >> opinion. > > On what grounds do you not think that? PL/J uses an external JVM, > PL/Java one that is running in the backend process. (Or maybe it was > the other way 'round, I'm too tired to remember tonight.) That's a > really fundamental difference that makes them suited for very > different > applications; not to mention the resulting different licensing > scenarios. No, this is correct. > > The points that have been made in this thread about PL/J not being > actively maintained are important, but other than that objection, I expect to see a new release shortly. > I can see no reason that PL/J wouldn't have an equal claim to > inclusion > in core. Perhaps more, because it gives us an extra layer of > insulation > from JVM licensing questions. > > regards, tom lane >
Dave Cramer wrote: > > I expect to see a new release shortly. Dave, I tried to obtain the source but whenever I try I get: [thhal]$ cvs -d :pserver:anonymous@cvs.plj.codehaus.org:/home/projects/plj/scm login Logging in to :pserver:anonymous@cvs.plj.codehaus.org:2401/home/projects/plj/scm CVS password: /home/projects/plj/scm: no such repository I can browse the source using the web interface though. Judging from that, there's been no CVS activity since I last tried, i.e. august last year. Is the source being maintained somewhere else? How do I obtain the latest CVS? Judging from your statement a lot must have happened that would be interesting to look at. Regards, Thomas Hallgren
Tom Lane wrote: > ... equal claim to inclusion > in core. Perhaps more, because it gives us an extra layer of insulation > from JVM licensing questions. > Tom, Why to you persist talking about licensing issues with PL/Java? There are none. PL/Java builds and runs just fine with gcj and the above statement is completely false. Dave, What JVM requirements does PL/J currently have? What license implications are imposed by the components that it depends upon? Regards, Thomas Hallgren
Thomas Hallgren wrote:
> Tom Lane wrote:
>> ... equal claim to inclusion
>> in core. Perhaps more, because it gives us an extra layer of insulation
>> from JVM licensing questions.
>>
> Tom,
> Why to you persist talking about licensing issues with PL/Java? There
> are none. PL/Java builds and runs just fine with gcj and the above
> statement is completely false.
Just to further this with actual documentation :)
1.1 What license is used for libgcj?
libgcj is distributed under the GPL, with the 'libgcc exception'.
This means that linking with libgcj does not by itself cause your
program to fall under the GPL. See LIBGCJ_LICENSE in the source tree for
more details.
Sincerely,
Joshua D. Drake
>
> Dave,
> What JVM requirements does PL/J currently have? What license
> implications are imposed by the components that it depends upon?
>
> Regards,
> Thomas Hallgren
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL
solutionssince 1997 http://www.commandprompt.com/
Thomas, I'm starting to have second thoughts about this suggestion. I was enthusiastic about it at the summit, but I was unaware of the sheer size of PL/Java. 38,000 lines of code is 8% of the total size of Postgresql ... for *one* PL. Dave Cramer acquainted me with some of the difficulties of doing a Java PL today, and I understand why it needs to be that large. However, 38,000 lines of code -- much of it in a non-C language -- presents a possible debugging/maintenance major headache, especially if you someday left the project for some reason. Maybe we do need to look at a plug-in build tool, instead. > Perhaps it's no surprise that I disagree when you say PL/J could be > considered in the same light as PL/Java. Then again, I'm fairly biased ;-) This attitude does you no credit, Thomas. --Josh Berkus
Tom, Perhaps more, because it gives us an extra layer of insulation > from JVM licensing questions. I really don't see licensing issues as being relevant. Your other concern certainly is, though. --Josh
Josh Berkus wrote: > >> Perhaps it's no surprise that I disagree when you say PL/J could be >> considered in the same light as PL/Java. Then again, I'm fairly >> biased ;-) > > This attitude does you no credit, Thomas. > My diplomatic skills are somewhat limited :-) I might be blunt at times. I'm sure there are other more subtle ways to get the message through. I'm trying to be honest and up-front. IMO, that should count for something. Regards, Thomas Hallgren
Thomas Hallgren wrote: > Tom Lane wrote: >> Thomas Hallgren <thomas@tada.se> writes: >> >>> Why to you persist talking about licensing issues with PL/Java? There >>> are none. PL/Java builds and runs just fine with gcj and the above >>> statement is completely false. >>> >> >> Um ... if you use it with gcj, there may or may not be any licensing >> problems (please recall we are trying to be a BSD-only project, not a >> BSD-and-LGPL project), > You have no problems using gcc, gnu-make, etc. What's the difference? Well there is a couple of literal differences. gcc, gnu-make are irrelevant. What is relevant is libc which is LGPL. Gcj IS GPL, not LGPL :( it just has an exception clause Keep in mind that that there are all kinds of oddities when mixing licenses. Is Sun's JVM GPL compatible? If not, the plJava can't use it. What happens when the FSF inevitably removes the license clause and makes it pure GPL? Now all of this being said, I doubt there is actually an issue here because: It doesn't HAVE TO BE BUILT, it is not a derivative product. It doesn't ship with the JVM which means it is up to the user to break the license not the PostgreSQL project... However that last one is bad mojo :( Sincerely, Joshua D. Drake > >> but what of people who use some other JVM? >> It's not like gcj works for everyone yet. >> >> > What of them? If they decide to use another JVM, well, then let them. I > don't see where that becomes a licensing problem from PostgreSQL. > > Regards, > Thomas Hallgren > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Thomas Hallgren <thomas@tada.se> writes:
> Why to you persist talking about licensing issues with PL/Java? There are none. PL/Java
> builds and runs just fine with gcj and the above statement is completely false.
Um ... if you use it with gcj, there may or may not be any licensing
problems (please recall we are trying to be a BSD-only project, not a
BSD-and-LGPL project), but what of people who use some other JVM?
It's not like gcj works for everyone yet.
regards, tom lane
Tom Lane wrote: > Thomas Hallgren <thomas@tada.se> writes: > >> Why to you persist talking about licensing issues with PL/Java? There are none. PL/Java >> builds and runs just fine with gcj and the above statement is completely false. >> > > Um ... if you use it with gcj, there may or may not be any licensing > problems (please recall we are trying to be a BSD-only project, not a > BSD-and-LGPL project), You have no problems using gcc, gnu-make, etc. What's the difference? > but what of people who use some other JVM? > It's not like gcj works for everyone yet. > > What of them? If they decide to use another JVM, well, then let them. I don't see where that becomes a licensing problem from PostgreSQL. Regards, Thomas Hallgren
Joshua D. Drake wrote: > What happens when the FSF inevitably removes the license clause and > makes it pure GPL? > I'm sorry but I don't follow. You're saying that it's inevitable that FSF will remove the 'libgcc' exception from libgcj? Why on earth would they do that? My guess is that it will go the other way (i.e. LGPL). What's the logic in having different licenses on libg++ and libgcj? > Now all of this being said, I doubt there is actually an issue here > because: > > It doesn't HAVE TO BE BUILT, it is not a derivative product. > Well, assume that FSF indeed did remove the exception. It would take me 30 minutes or so to create a substitute BSD licensed dummy JNI library with associated headers that would allow PL/Java to be built without any external modules at all. It's then completely up to the user what he/she wants to slot in as a replacement. Regards, Thomas Hallgren
Josh Berkus wrote: > Thomas, > > I'm starting to have second thoughts about this suggestion. I was > enthusiastic about it at the summit, but I was unaware of the sheer size > of PL/Java. 38,000 lines of code is 8% of the total size of Postgresql > ... for *one* PL. > > Dave Cramer acquainted me with some of the difficulties of doing a Java > PL today, and I understand why it needs to be that large. However, > 38,000 lines of code -- much of it in a non-C language -- presents a > possible debugging/maintenance major headache, especially if you someday > left the project for some reason. > OK. You're the one that suggested this submission attempt. There's not much point in pursuing it if you have second thoughts. > Maybe we do need to look at a plug-in build tool, instead.> Right, something that would allow PL/Java to participate in a build farm. That would be cool and also resolve a some of the issues. Regards, Thomas Hallgren
> Well, assume that FSF indeed did remove the exception. It would take me > 30 minutes or so to create a substitute BSD licensed dummy JNI library > with associated headers that would allow PL/Java to be built without any > external modules at all. It's then completely up to the user what he/she > wants to slot in as a replacement. Do we want to do that? I mean (and I am not saying it is, I am asking) is that a bit grey? I would prefer it be black and white. Are their JVMs that are BSD compatible? It is my understanding that you can ship Java (I could be completely on crack here) in a closed source product without issue right? If so... then wouldn't our argument be to strongly suggest that they use the Sun JVM (or IBM if that is relevant?). Sincerely, Joshua D. Drake > > Regards, > Thomas Hallgren > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: > >> Well, assume that FSF indeed did remove the exception. It would take >> me 30 minutes or so to create a substitute BSD licensed dummy JNI >> library with associated headers that would allow PL/Java to be built >> without any external modules at all. It's then completely up to the >> user what he/she wants to slot in as a replacement. > > Do we want to do that? I mean (and I am not saying it is, I am asking) > is that a bit grey? I would prefer it be black and white. > The JNI API is an open standard so I have every right to create a BSD licensed dummy for it. The user may choose a JVM from IBM, Sun, BEA, or other (like GCJ) to run. That's the essence of having a standardized API. What can possibly be 'grey' about that? Regards, Thomas Hallgren
Thomas Hallgren wrote: > Joshua D. Drake wrote: >> What happens when the FSF inevitably removes the license clause and >> makes it pure GPL? >> > I'm sorry but I don't follow. You're saying that it's inevitable that > FSF will remove the 'libgcc' exception from libgcj? Why on earth would > they do that? My guess is that it will go the other way (i.e. LGPL). > What's the logic in having different licenses on libg++ and libgcj? You are trying to apply logic to what is a political organization. Keep in mind that LGPL stands for LESSOR GPL. RMS would prefer that ALL licenses be under the GPL (or something very similar) that does not allow anyone to close source the software. This isn't really the point of the thread though. Sincerely, Joshua D. Drake > >> Now all of this being said, I doubt there is actually an issue here >> because: >> >> It doesn't HAVE TO BE BUILT, it is not a derivative product. >> > Well, assume that FSF indeed did remove the exception. It would take me > 30 minutes or so to create a substitute BSD licensed dummy JNI library > with associated headers that would allow PL/Java to be built without any > external modules at all. It's then completely up to the user what he/she > wants to slot in as a replacement. > > Regards, > Thomas Hallgren > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Will this patch make it into 8.2? http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php It's a really nice feature, would be extremly useful with tools like pgpool. Am Freitag, 7. Juli 2006 19:13 schrieb Bruce Momjian: > There are roughly three weeks left until the feature freeze on August 1. > If people are working on items, they should be announced before August > 1, and the patches submitted by August 1. If the patch is large, it > should be discussed now and an intermediate patch posted to the lists > soon. > > FYI, we don't have many major features ready for 8.2. > > -- > Bruce Momjian bruce@momjian.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings
Thomas, > OK. You're the one that suggested this submission attempt. There's not > much point in pursuing it if you have second thoughts. Yes. I was unclear on the requirements. I was thinking of it being "just like PL/perl". > Right, something that would allow PL/Java to participate in a build Unfortunately, it's not exactly an easy task. --Josh
On 7/13/06, Josh Berkus <josh@agliodbs.com> wrote: > I'm starting to have second thoughts about this suggestion. I was > enthusiastic about it at the summit, but I was unaware of the sheer size > of PL/Java. 38,000 lines of code is 8% of the total size of Postgresql > ... for *one* PL. Josh, I still don't see the problem; 38K lines of code really isn't that much. I have personal proof-of-concept projects bigger than that. The question really is whether it's going to be maintained and by whom. Tom, Neil, et al will not be the ones maintaining it on a regular basis. > Dave Cramer acquainted me with some of the difficulties of doing a Java > PL today, and I understand why it needs to be that large. However, > 38,000 lines of code -- much of it in a non-C language -- presents a > possible debugging/maintenance major headache, especially if you someday > left the project for some reason. Again, I guess it comes down to what we're willing to let go. If we want new users who want certain functionality in the system to be happy, we include it. Otherwise, we do as we do now, keeping tons of projects on pgfoundry and hoping a user doesn't just pass us by because they installed PostgreSQL and didn't see the things they want/need in the core. Of course, this will last until MySQL goes ahead and adds a Java PL and the user doesn't even glance over at us... but I guess that falls back to the argument of, "what kind of user do we really want". Almost everyone here who's ever done real-world consulting on PostgreSQL has run into PL/Java at some point in time, so it is used and used often. > This attitude does you no credit, Thomas. That may be, but I completely understand Thomas' frustration. This topic wasn't his idea yet his project is being bashed on pretty well. If you know of some way to turn 38K lines of code into 5K, or can magically translate Java code to C, he may be open to it... but complaining about something someone spent free-time on devotedly for several years is just going to cause problems... neither is making arguments by comparing it to a much less complete implementation. The point is, this is just politics without common sense. PL/Java works and works well, if you haven't used it or PL/J, please don't talk about it like you know it; it just spreads misinformation through the forum. The fact is that a lot of people use PL/Java, you asked about including it in the core, it's a stable PL, and Thomas is willing to continue maintaining and improving it. My vote is that we add it to the core and let him continue to do so. As for the JVM worries, it's perfectly fine for anyone to ship the JVM. If we wanted to include the JVM in official PostgreSQL distributions, we can do so. Otherwise, we can just rely on the user to have a JVM installed. Better yet, Sun supports PostgreSQL, so get them to do a specific distribution license. There aren't that many options so I don't see the need to plan contingencies ad nauseam. I don't believe anyone has offered any suggestions or good alternatives other than what we have now; keeping high-profile projects like PL/Java on gborg/pgfoundry (which sucks IMHO). -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
* Joshua D. Drake (jd@commandprompt.com) wrote:
> Keep in mind that that there are all kinds of oddities when mixing
> licenses. Is Sun's JVM GPL compatible? If not, the plJava can't use it.
I'm about 95% sure that Sun's JVM *isn't* GPL compatible... Makes for a
pretty odd situation if someone licensed a Java app which only works
with Sun's JVM under the GPL. The combination of the Java app with
Sun's JVM then becomes impossible to distribute. This is more a problem
with the GPL's 'no additional restrictions' clause than anything else,
but, well, the GPL is pretty popular. :/
> It doesn't HAVE TO BE BUILT, it is not a derivative product.
Many distributions try to build all the parts of a given application
since otherwise someone will almost certainly ask for it. Therefore,
I'm not really sure this is a great argument.
> It doesn't ship with the JVM which means it is up to the user to break
> the license not the PostgreSQL project...
It's not the PostgreSQL project's problem, that's true, but it certainly
becomes an issue for distributions. Java as a PL ends up being a pretty
odd case.. If there isn't anything in the PL code itself which forces a
dependency beyond gcj then it might be possible to distribute it. Also
allowing the PL to use a different JVM shouldn't be a problem so long as
nothing is distributed which depends on the alternate JVM. The GPL is
all about distribution and so I'm not sure that it would actually be a
problem for an end-user to use Sun's JVM with GPL'd Java code.
Anyhow, if people are really interested in these issues as they relate
to a distribution, it might make sense to bring it up on debian-legal...
Thanks,
Stephen
On 7/12/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I don't really think anyone would want to run both, but > > that's just my opinion. > > On what grounds do you not think that? Too much Java overhead on one database and PL/J isn't that stable. I've run into several crash problems with it before. > PL/J uses an external JVM, PL/Java one that is running in the > backend process. (Or maybe it was the other way 'round, I'm too > tired to remember tonight.) While tired, you're still correct :) > That's a really fundamental difference that makes them suited for very different > applications; not to mention the resulting different licensing scenarios. Not really, both require a JVM so the same licensing still applies. > The points that have been made in this thread about PL/J not being > actively maintained are important, but other than that objection, > I can see no reason that PL/J wouldn't have an equal claim to inclusion > in core. I'm being objective here, and PL/J is not nearly as stable or well-maintained... that means a lot to me or to anyone who looks at using a Java PL. Do we intend to ship both and say that one is less capable? Have you used either of them? Don't get me wrong, I like PL/J in concept... but it's just not even close to production-ready yet. I know of no one using PL/J in production and about 40 or so people using PL/Java. > Perhaps more, because it gives us an extra layer of insulation > from JVM licensing questions. Again, I don't believe so. I'd like to hear how Dave thinks so, though. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On 13-Jul-06, at 9:22 AM, Jonah H. Harris wrote: > On 7/13/06, Josh Berkus <josh@agliodbs.com> wrote: >> I'm starting to have second thoughts about this suggestion. I was >> enthusiastic about it at the summit, but I was unaware of the >> sheer size >> of PL/Java. 38,000 lines of code is 8% of the total size of >> Postgresql >> ... for *one* PL. > > Josh, > > I still don't see the problem; 38K lines of code really isn't that > much. I have personal proof-of-concept projects bigger than that. > The question really is whether it's going to be maintained and by > whom. Tom, Neil, et al will not be the ones maintaining it on a > regular basis. > >> Dave Cramer acquainted me with some of the difficulties of doing a >> Java >> PL today, and I understand why it needs to be that large. However, >> 38,000 lines of code -- much of it in a non-C language -- presents a >> possible debugging/maintenance major headache, especially if you >> someday >> left the project for some reason. > > Again, I guess it comes down to what we're willing to let go. If we > want new users who want certain functionality in the system to be > happy, we include it. Otherwise, we do as we do now, keeping tons of > projects on pgfoundry and hoping a user doesn't just pass us by > because they installed PostgreSQL and didn't see the things they > want/need in the core. Of course, this will last until MySQL goes > ahead and adds a Java PL and the user doesn't even glance over at > us... but I guess that falls back to the argument of, "what kind of > user do we really want". Almost everyone here who's ever done > real-world consulting on PostgreSQL has run into PL/Java at some point > in time, so it is used and used often. > >> This attitude does you no credit, Thomas. > > That may be, but I completely understand Thomas' frustration. This > topic wasn't his idea yet his project is being bashed on pretty well. > If you know of some way to turn 38K lines of code into 5K, or can > magically translate Java code to C, he may be open to it... but > complaining about something someone spent free-time on devotedly for > several years is just going to cause problems... neither is making > arguments by comparing it to a much less complete implementation. > > The point is, this is just politics without common sense. PL/Java > works and works well, if you haven't used it or PL/J, please don't > talk about it like you know it; it just spreads misinformation through > the forum. The fact is that a lot of people use PL/Java, you asked > about including it in the core, it's a stable PL, and Thomas is > willing to continue maintaining and improving it. My vote is that we > add it to the core and let him continue to do so. > > As for the JVM worries, it's perfectly fine for anyone to ship the > JVM. If we wanted to include the JVM in official PostgreSQL > distributions, we can do so. Otherwise, we can just rely on the user > to have a JVM installed. Better yet, Sun supports PostgreSQL, so get > them to do a specific distribution license. There aren't that many > options so I don't see the need to plan contingencies ad nauseam. > > I don't believe anyone has offered any suggestions or good > alternatives other than what we have now; keeping high-profile > projects like PL/Java on gborg/pgfoundry (which sucks IMHO). > The official JDBC driver is not being shipped with the project for exactly the same reasons, I fail to see any compelling reason to ship either java PL. Unless we are going to create a complete distribution with a unified build, or at least a way to build each project (which I am in favour of) then we leave the server to itself and all other projects exist separately. > -- > Jonah H. Harris, Software Architect | phone: 732.331.1300 > EnterpriseDB Corporation | fax: 732.331.1301 > 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com > Iselin, New Jersey 08830 | http://www.enterprisedb.com/ >
On Thu, 2006-07-13 at 15:29, Stephen Frost wrote: > It's not the PostgreSQL project's problem, that's true, but it certainly > becomes an issue for distributions. Java as a PL ends up being a pretty > odd case.. If there isn't anything in the PL code itself which forces a > dependency beyond gcj then it might be possible to distribute it. Also > allowing the PL to use a different JVM shouldn't be a problem so long as > nothing is distributed which depends on the alternate JVM. The GPL is > all about distribution and so I'm not sure that it would actually be a > problem for an end-user to use Sun's JVM with GPL'd Java code. Now I'm completely confused... what GPL code ? Is PL/Java licensed under the GPL ? Or what GPL code do you talk about ? The PL/Java code is likely only dependent on the JVM specification, which does not put any restriction on how you must license your code, so PL/Java can be licensed in any way the author wants, including BSD. The distribution part is also no problem as I see it, as only the build tools are not BSD, and they are available for free (including the Sun JDK) and they don't restrict what should be the license of the code you compile. This can only be a problem for purists like GPL zealots or perhaps debian, otherwise is not that hard to download and install the SUN JDK on a build machine... you don't need to distribute the JDK, only the runtime JVM, which you actually can do (including again the Sun runtime). So I can't see problems again from the packager point of view... except purists might put a separate pl/Java module in some "non-free" repository given the dependency on some "non-free" runtime... Cheers, Csaba.
Jonah H. Harris wrote: > Again, I guess it comes down to what we're willing to let go. If we > want new users who want certain functionality in the system to be > happy, we include it. Otherwise, we do as we do now, keeping tons of > projects on pgfoundry and hoping a user doesn't just pass us by > because they installed PostgreSQL and didn't see the things they > want/need in the core. Of course, this will last until MySQL goes > ahead and adds a Java PL and the user doesn't even glance over at > us... but I guess that falls back to the argument of, "what kind of > user do we really want". Almost everyone here who's ever done > real-world consulting on PostgreSQL has run into PL/Java at some point > in time, so it is used and used often. Aside from obviously the big issue of who maintains all the pgfoundry stuff, I also think that the PostgreSQL family would benefit from a distribution that is more "and the kitchen sink" style. I do not know exactly if Bizgres could be considered just that? Or maybe it could get promoted to be that? What I mean is I think it makes absolute sense to keep a very stable, very well maintained core PostgreSQL distribution which is that anyone should base their distributions on. However I do think that PostgreSQL is missing out in getting new users aboard that are in the early stages of evalutation and simply only consider features that they get along with a default installation (mostly due to lack of better knowledge about places like pgfoundry). For these kinds of users it would make sense to provide a distro that has an extended feature list, while sacrificing maybe a tiny bit of stability because it adds modules that do not adhere to the same high level of maintaince as PostgreSQL core does. regards, Lukas
On 7/13/06, Lukas Smith wrote: > However I do think that PostgreSQL is missing out in > getting new users aboard that are in the early stages > of evalutation and simply only consider features that > they get along with a default installation (mostly due > to lack of better knowledge about places like pgfoundry). This is my point exactly. As with many things, we keep skirting the real issue by going with an "improve the smaller component" approach such as "promote pgfoundry more". I have never seen this approach work, but maybe someone has an example of another OSS project that has successfully excluded major components like this? No matter what we want people to do, if someone wants PostgreSQL, they go to PostgreSQL's site, download PostgreSQL, and install PostgreSQL. The fact is, most people generally don't read the, "don't see it in the distribution, check out pgfoundry"-like text. Sure, people should read the docs, but most don't until they have to (which is long after getting the software). Do we even have anything in the actual manual that talks about gborg or pgfoundry? > For these kinds of users it would make sense to provide > a distro that has an extended feature list, while sacrificing > maybe a tiny bit of stability I don't see it as less stable at all. If someone needs functionality (and doesn't just decide to get a different RDBMS that has it included), they're going to get the pgfoundry project anyway... so whether we include it in the distro is seemingly irrelevant from a stability standpoint. What we should say is something to the effect of, "this version of [pgfoundry project X] has been tested successfully with PostgreSQL x.x.x." The core distro has nothing to do with the add-ons which are inevitably added by the user after the fact... but at least we wouldn't lose potentially new users. My question is, what is the packagers' stance on this topic? It seems like more work for them than for anyone else. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
Dave Cramer <pg@fastcrypt.com> writes:
> The official JDBC driver is not being shipped with the project for
> exactly the same reasons, I fail to see any compelling reason to ship
> either java PL.
> Unless we are going to create a complete distribution with a unified
> build, or at least a way to build each project (which I am in favour
> of) then we leave the server to itself and all other projects exist
> separately.
The only argument I find interesting for including the PLs in core
(which has zilch to do with how any particular packager ships them)
is that it's easier to do maintenance that way: if we make a change in
an API that affects the PLs, we can change the PLs at the same time.
However, that argument only holds water if the core developers are
able/willing to make the corresponding changes. And in that light,
the fact that PL/Java includes a huge whack of non-C code is very
significant. *I* won't take responsibility for fixing PL/Java when
I break it, because I don't know Java well enough. I don't know what
other people who do core development feel about that --- but I dislike
the idea that when someone changes such an API, the buildfarm will go
all red because there's only one person with the ability to fix PL/Java.
regards, tom lane
Forwarded to -hackers. Jonah H. Harris wrote: > Again, I guess it comes down to what we're willing to let go. If we > want new users who want certain functionality in the system to be > happy, we include it. Otherwise, we do as we do now, keeping tons of > projects on pgfoundry and hoping a user doesn't just pass us by > because they installed PostgreSQL and didn't see the things they > want/need in the core. Of course, this will last until MySQL goes > ahead and adds a Java PL and the user doesn't even glance over at > us... but I guess that falls back to the argument of, "what kind of > user do we really want". Almost everyone here who's ever done > real-world consulting on PostgreSQL has run into PL/Java at some point > in time, so it is used and used often. Aside from obviously the big issue of who maintains all the pgfoundry stuff, I also think that the PostgreSQL family would benefit from a distribution that is more "and the kitchen sink" style. I do not know exactly if Bizgres could be considered just that? Or maybe it could get promoted to be that? What I mean is I think it makes absolute sense to keep a very stable, very well maintained core PostgreSQL distribution which is that anyone should base their distributions on. However I do think that PostgreSQL is missing out in getting new users aboard that are in the early stages of evalutation and simply only consider features that they get along with a default installation (mostly due to lack of better knowledge about places like pgfoundry). For these kinds of users it would make sense to provide a distro that has an extended feature list, while sacrificing maybe a tiny bit of stability because it adds modules that do not adhere to the same high level of maintaince as PostgreSQL core does. regards, Lukas
On 7/13/06, Dave Cramer <pg@fastcrypt.com> wrote: > Doesn't EDB sponsor pl/java ? I would think that might make you > somewhat subjective ? I believe we do, but that has nothing to do with my statements. I've used both PL/Java and PL/J before coming to EnterpriseDB and am making true observations. > That being said, pl-j is not as mature as pl/java, however I don't > believe that is a valid reason for exclusion. So, I was being objectionable then... > Open source projects by their nature gain maturity by exposure. Open source projects gain maturity through continued improvement and maintenance... I can name hundreds of cool open source projects I've used that have died because they were once popular, but no one maintained them on a consistent basis. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On Thu, Jul 13, 2006 at 09:29:06AM -0400, Jonah H. Harris wrote:
> I'm being objective here, and PL/J is not nearly as stable or
> well-maintained... that means a lot to me or to anyone who looks at
> using a Java PL. Do we intend to ship both and say that one is less
> capable? Have you used either of them? Don't get me wrong, I like
> PL/J in concept... but it's just not even close to production-ready
> yet. I know of no one using PL/J in production and about 40 or so
> people using PL/Java.
On the subject of 38K lines of code, much that isn't C (going by memory,
I apologize if this is wrong), how many of these lines could be/should be
shared between PL/Java and PL/J? It seems to me that the general concepts
should be in common, and that it is only how the Java interfaces with the
backend that changes. Could they not be one PL, with two mechanisms for
speaking to the backend?
I agree with competition to improve quality, but at some point, with
too few maintainers, and one project clearly more advanced in terms of
maturity than the other, that perhaps having two separate projects
does not make sense. It sounds to me like PL/Java is rich in terms of
PostgreSQL abstractions, and that this shouldn't be a reason to
penalize it. Does it really matter how much Java code there is in it?
It's only the C code that needs to interface with the backend.
Or perhaps I'm out to lunch, and the PL/Java abstractions are tightly
tied to the backend API, and there is thousands of lines of unnecessary
code.
Now you are going to make me try them both out. I have not tried either.
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness
bindthem...
http://mark.mielke.cc/
On 7/13/06, Dave Cramer <pg@fastcrypt.com> wrote: > The official JDBC driver is not being shipped with the project for > exactly the same reasons, I fail to see any compelling reason to ship > either java PL. IMHO, we should be shipping the JDBC driver... but that's another matter entirely. > Unless we are going to create a complete distribution with a unified > build, or at least a way to build each project (which I am in favour > of) then we leave the server to itself and all other projects exist > separately. This still doesn't solve the longstanding issue of what we do include and what we don't... and more importantly, the process for determining what to include and what not to. The Java PL discussion could be the same as say, OBDC drivers... where multiple projects exist and each has pros/cons. When someone downloads the PostgreSQL server on Windows... we know they're probably going to be using ODBC... so we should ship it; but which one? How do we determine which one as a community? Eventually we need to evolve a little bit and tackle these types of issues; I don't think gborg or pgfoundry are the best places for high-profile, commonly used PostgreSQL drivers, PLs, or functions. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On 13-Jul-06, at 9:29 AM, Jonah H. Harris wrote: > On 7/12/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> > I don't really think anyone would want to run both, but >> > that's just my opinion. >> >> On what grounds do you not think that? > > Too much Java overhead on one database and PL/J isn't that stable. > I've run into several crash problems with it before. > >> PL/J uses an external JVM, PL/Java one that is running in the >> backend process. (Or maybe it was the other way 'round, I'm too >> tired to remember tonight.) > > While tired, you're still correct :) > >> That's a really fundamental difference that makes them suited for >> very different >> applications; not to mention the resulting different licensing >> scenarios. > > Not really, both require a JVM so the same licensing still applies. > >> The points that have been made in this thread about PL/J not being >> actively maintained are important, but other than that objection, >> I can see no reason that PL/J wouldn't have an equal claim to >> inclusion >> in core. > > I'm being objective here, and PL/J is not nearly as stable or > well-maintained... that means a lot to me or to anyone who looks at > using a Java PL. Doesn't EDB sponsor pl/java ? I would think that might make you somewhat subjective ? That being said, pl-j is not as mature as pl/java, however I don't believe that is a valid reason for exclusion. Open source projects by their nature gain maturity by exposure. > Do we intend to ship both and say that one is less > capable? Have you used either of them? Don't get me wrong, I like > PL/J in concept... but it's just not even close to production-ready > yet. I know of no one using PL/J in production and about 40 or so > people using PL/Java. > >> Perhaps more, because it gives us an extra layer of insulation >> from JVM licensing questions. > > Again, I don't believe so. I'd like to hear how Dave thinks so, > though. I didn't say this > > -- > Jonah H. Harris, Software Architect | phone: 732.331.1300 > EnterpriseDB Corporation | fax: 732.331.1301 > 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com > Iselin, New Jersey 08830 | http://www.enterprisedb.com/ >
Tom Lane wrote: > Dave Cramer <pg@fastcrypt.com> writes: > > The official JDBC driver is not being shipped with the project for > > exactly the same reasons, I fail to see any compelling reason to ship > > either java PL. > > > Unless we are going to create a complete distribution with a unified > > build, or at least a way to build each project (which I am in favour > > of) then we leave the server to itself and all other projects exist > > separately. > > The only argument I find interesting for including the PLs in core > (which has zilch to do with how any particular packager ships them) > is that it's easier to do maintenance that way: if we make a change in > an API that affects the PLs, we can change the PLs at the same time. > However, that argument only holds water if the core developers are > able/willing to make the corresponding changes. And in that light, > the fact that PL/Java includes a huge whack of non-C code is very > significant. *I* won't take responsibility for fixing PL/Java when > I break it, because I don't know Java well enough. I don't know what > other people who do core development feel about that --- but I dislike > the idea that when someone changes such an API, the buildfarm will go > all red because there's only one person with the ability to fix PL/Java. I also cannot maintain Java, but we could do something like we do with WIN32, where outside folks submit patches to fix problems. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Thu, 2006-07-13 at 11:03 -0400, Jonah H. Harris wrote: > On 7/13/06, Lukas Smith wrote: > > However I do think that PostgreSQL is missing out in > > getting new users aboard that are in the early stages > > of evalutation and simply only consider features that > > they get along with a default installation (mostly due > > to lack of better knowledge about places like pgfoundry). > > This is my point exactly. As with many things, we keep skirting the > real issue by going with an "improve the smaller component" approach > such as "promote pgfoundry more". I have never seen this approach > work, but maybe someone has an example of another OSS project that has > successfully excluded major components like this? Personally, I prefer the Gnome approach. Most components are developed and bundled independently but once the code meets certain stability and usability requirements the component is promoted to the standard website with standard documentation, bug reporting, download locations, etc. On PostgreSQL.org, aside from the "Downloads" tab it is very difficult to find these items. PGFoundry does not attempt to differentiate between the state of projects. Top downloads is the closest to this. XML based docbook can easily suck in documentation from multiple remote sources (when available -- substituted when not available) for a single documentation build via XMLIncludes. This allows for PL/Java chapter in the standard documentation set online. PostgreSQL.org "Support" could pretty easily link to the various locations for bug reports -- Bugzilla makes component selection a common requirement. A slight restructuring of the FTP tree should probably be made. It's currently very easy to find the main pgsql, pgadmin and odbc components. Finding pl/java (what the heck is that gborg or pgfoundry project?) is pretty difficult. The only real tricky part is defining what a plugin or addon application such as pgadmin needs to be considered production ready. This will relate to testing practices, documentation, code quality, ongoing maintenance, and expected supported lifetime. For lifetime, if it was released for Core 7.3 should still work with 7.3 today or old versions should still receive security and bug fixes. --
On Thu, 2006-07-13 at 17:03, Tom Lane wrote: > [...] I don't know what > other people who do core development feel about that --- but I dislike > the idea that when someone changes such an API, the buildfarm will go > all red because there's only one person with the ability to fix PL/Java. But the alternative is that nothing is going red, and the PL stays broken until somebody notices it which might be too late to easily know which change broke it. Wouldn't it be possible to separate the "red/green lights" for the core and for the PLs ? So the core stays green and the PLs go red... and stay red until the PL maintainer fixes things. And I don't believe there's only one man who knows good Java around... once PL/Java gets in the core I'm pretty sure there will be a lot of people using it and caring about it. Cheers, Csaba.
On Thu, Jul 13, 2006 at 11:03:27AM -0400, Tom Lane wrote:
> The only argument I find interesting for including the PLs in core
> (which has zilch to do with how any particular packager ships them)
> is that it's easier to do maintenance that way: if we make a change in
> an API that affects the PLs, we can change the PLs at the same time.
> However, that argument only holds water if the core developers are
> able/willing to make the corresponding changes. And in that light,
> the fact that PL/Java includes a huge whack of non-C code is very
> significant. *I* won't take responsibility for fixing PL/Java when
> I break it, because I don't know Java well enough. I don't know what
> other people who do core development feel about that --- but I dislike
> the idea that when someone changes such an API, the buildfarm will go
> all red because there's only one person with the ability to fix PL/Java.
Tom:
Currently, the PL implementations combine both language-specific glue
and language-specific abstractions together. In light of your comments
below, and the opinion I expressed in my previous response, I find
myself wondering whether this architecture is contributing to the
problem.
Would it make sense for this architecture to be split?
My thinking is that much of the code in the Perl, TCL, Java, ... PL
implementations is related to language-specific abstractions and
documentation, and does not need to be bundled with the core, nor
does it need to be tested as a part of the core. For example, I imagine
that many of the lines in PL/Java could be distributed as a single
hardware-independent .jar file separate from the core, if the core
exposed the required API to Java.
Where this could go, is that the core developers would only be
responsible for ensuring that the backend API functions as documented,
without needing to understand how these functions are exposed to the
user. You agree to maintain Java interfaces to the C functions. No more,
no less. If somebody else wants to build complicated abstractions on top,
or wants to provide thousands of pages of documentation - this is their
choice, but would be distributed separate from the core, but would be
simple to plug in.
Am I just spitting crazy talk, or is this making sense?
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness
bindthem...
http://mark.mielke.cc/
Am Donnerstag, 13. Juli 2006 16:48 schrieb Jonah H. Harris: > What I mean is I think it makes absolute sense to keep a very stable, > very well maintained core PostgreSQL distribution which is that anyone > should base their distributions on. I don't want to get into an operating system bout here, but there are a number of systems out there that include a fair amount of PostgreSQL-related software in packaged and readily available form, and will accept your contribution if anything is missing. I seriously doubt that providing one big PostgreSQL *source* distribution will help that process in any way. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Thu, July 13, 2006 11:03 am, Jonah H. Harris wrote: > This is my point exactly. As with many things, we keep skirting the > real issue by going with an "improve the smaller component" approach such > as "promote pgfoundry more". I have never seen this approach work, but > maybe someone has an example of another OSS project that has successfully > excluded major components like this? Perl? CPAN? Many modules are included but how they are chosen is somewhat arbitrary. However, those modules can be updated from CPAN (without redownloading Perl).
On 7/13/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > The only argument I find interesting for including the PLs in core > (which has zilch to do with how any particular packager ships them) > is that it's easier to do maintenance that way: if we make a change in > an API that affects the PLs, we can change the PLs at the same time. Very true. > However, that argument only holds water if the core developers are > able/willing to make the corresponding changes. Again, this is very true as well. > in that light, the fact that PL/Java includes a huge whack of > non-C code is very significant. *I* won't take responsibility > for fixing PL/Java when I break it, because I don't know Java > well enough. I don't think anyone expects you to. I certainly feel that PostgreSQL is a community... we all suffer if no one steps up to help fix something that's busted. We all rely on eachother in one way or another, and I don't see something as important as a fairly mature PL getting dumped on anyone... there's a lot of Java people out there that could maintain it if Thomas doesn't want to someday, or we can remove it altogether if it starts to compromise the core... but I see a lot of work that's been done over several years and Thomas has stepped up to the plate each time there has been some incompatibility or issue between PostgreSQL and PL/Java; I see no reason why this wouldn't be the case going forward. > I don't know what other people who do core development feel > about that --- but I dislike the idea that when someone changes > such an API, the buildfarm will go all red because there's only > one person with the ability to fix PL/Java. There's many of us that *can* fix it... I'm a Java developer as well, but I wouldn't choose to work on PL/Java by default because that's not my area of interest. If, however, the core was suffering from an issue with it, personal interests aren't as relevant. Again, we all rely on one another... I'm optimistic that we can make these types of things work out successfully. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
> Aside from obviously the big issue of who maintains all the pgfoundry > stuff, I also think that the PostgreSQL family would benefit from a > distribution that is more "and the kitchen sink" style. I do not know > exactly if Bizgres could be considered just that? Or maybe it could get > promoted to be that? Lukas, that is what www.mammothpostgresql.org is :) Sincerely, Joshua D. Drake > > What I mean is I think it makes absolute sense to keep a very stable, > very well maintained core PostgreSQL distribution which is that anyone > should base their distributions on. However I do think that PostgreSQL > is missing out in getting new users aboard that are in the early stages > of evalutation and simply only consider features that they get along > with a default installation (mostly due to lack of better knowledge > about places like pgfoundry). For these kinds of users it would make > sense to provide a distro that has an extended feature list, while > sacrificing maybe a tiny bit of stability because it adds modules that > do not adhere to the same high level of maintaince as PostgreSQL core does. > > regards, > Lukas > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Bruce Momjian <bruce@momjian.us> writes:
> I also cannot maintain Java, but we could do something like we do with
> WIN32, where outside folks submit patches to fix problems.
However, a win32 failure breaks only the win32 buildfarm members ...
Basically my point here is that I see no synergy from having PL/Java
(or PL/J for that matter) in core. They can't share the same configure
or build support as the rest of the code; the core developers don't feel
qualified to maintain them; what's left?
The argument in favor boils down to one and only one thing: bundling
PL/Java will improve the visibility of PL/Java to people who won't go
looking for it. That's fine, but ultimately that's a packaging argument
not a development argument. The people who think PL/Java is an
essential checklist item undoubtedly also think JDBC is an essential
checklist item, but I'm not seeing any groundswell of support for
putting JDBC back into core. Instead we expect packagers (like the RPM
set) to make JDBC available alongside the core postgres packages.
That's how PL/Java ought to be handled, too, IMHO.
In my own experience dealing with the Red Hat RPMs, it got a whole lot
easier to package JDBC correctly once it wasn't mis-bundled into a
basically non-Java source tarball, so I think that the packagers will
also find that keeping it separate makes their lives easier.
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Lane wrote: > And in that light, the fact that PL/Java includes a huge whack of > non-C code is very significant. *I* won't take responsibility for > fixing PL/Java when I break it, because I don't know Java well enough. That's the heart of the matter - PostgreSQL is a C project. All of the other languages we use for PL/*, such as Perl, PHP, R, tcl, Python, etc. are, at their heart, written in C. That's why I think comparing pl/java to other pl languages is not apples to apples. Like Tom, I am also uneasy about putting so much non-C code into the core. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200607131300 End Point Corporation http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFEtn00vJuQZxSWSsgRArG0AKC+PnCbgWWE2pT/8iMVCvnq0bhfSACg3rgF qpcQ2OaB5K0KkiYzE3jp+50= =E1rs -----END PGP SIGNATURE-----
> When someone downloads the PostgreSQL server on Windows... we know > they're probably going to be using ODBC... so we should ship it; but > which one? How do we determine which one as a community? Actually, this comes back to another scenario... There has been a longstanding practice of letting distribution handlers deal with all of this. E.g; PostgreSQL is the core database. Anything external can be packaged by someone else. This is the whole reason mammothpostgresql.org exists. > Eventually we need to evolve a little bit and tackle these types of > issues; I don't think gborg or pgfoundry are the best places for > high-profile, commonly used PostgreSQL drivers, PLs, or functions. Well that would certainly depend on the goal of the project. To me, it is not a big deal if we do or don't include PL/Java because we will include it in mammothpostgresql.org. What is a mistake to me, is including two projects that provide near functionality. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Csaba Nagy wrote: > On Thu, 2006-07-13 at 15:29, Stephen Frost wrote: >> It's not the PostgreSQL project's problem, that's true, but it certainly >> becomes an issue for distributions. Java as a PL ends up being a pretty >> odd case.. If there isn't anything in the PL code itself which forces a >> dependency beyond gcj then it might be possible to distribute it. Also >> allowing the PL to use a different JVM shouldn't be a problem so long as >> nothing is distributed which depends on the alternate JVM. The GPL is >> all about distribution and so I'm not sure that it would actually be a >> problem for an end-user to use Sun's JVM with GPL'd Java code. > > Now I'm completely confused... what GPL code ? Is PL/Java licensed under > the GPL ? Or what GPL code do you talk about ? What was a mistake on my part. I was tired when I wrote the part about GPL. Sincerely, Joshua D. Drake > > The PL/Java code is likely only dependent on the JVM specification, > which does not put any restriction on how you must license your code, so > PL/Java can be licensed in any way the author wants, including BSD. > > The distribution part is also no problem as I see it, as only the build > tools are not BSD, and they are available for free (including the Sun > JDK) and they don't restrict what should be the license of the code you > compile. This can only be a problem for purists like GPL zealots or > perhaps debian, otherwise is not that hard to download and install the > SUN JDK on a build machine... you don't need to distribute the JDK, only > the runtime JVM, which you actually can do (including again the Sun > runtime). So I can't see problems again from the packager point of > view... except purists might put a separate pl/Java module in some > "non-free" repository given the dependency on some "non-free" runtime... > > Cheers, > Csaba. > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
>> I'm being objective here, and PL/J is not nearly as stable or >> well-maintained... that means a lot to me or to anyone who looks at >> using a Java PL. > Doesn't EDB sponsor pl/java ? I would think that might make you somewhat > subjective ? Dave, I don't think so in this situation. It is in EDB's best interest to sponsor the product that works best for them. Right now (maybe not for everyone) that is clearly pl/java. > That being said, pl-j is not as mature as pl/java, however I don't > believe that is a valid reason for exclusion. > Open source projects by their nature gain maturity by exposure. It is a valid reason if it is going to be in core. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Tom Lane wrote: >Dave Cramer <pg@fastcrypt.com> writes: > > >>The official JDBC driver is not being shipped with the project for >>exactly the same reasons, I fail to see any compelling reason to ship >>either java PL. >> >> > > > >>Unless we are going to create a complete distribution with a unified >>build, or at least a way to build each project (which I am in favour >>of) then we leave the server to itself and all other projects exist >>separately. >> >> > >The only argument I find interesting for including the PLs in core >(which has zilch to do with how any particular packager ships them) >is that it's easier to do maintenance that way: if we make a change in >an API that affects the PLs, we can change the PLs at the same time. > > Yes, exactly. And if you look back at the history of, say, plperl.c, you will find plenty of such instances. >However, that argument only holds water if the core developers are >able/willing to make the corresponding changes. And in that light, >the fact that PL/Java includes a huge whack of non-C code is very >significant. *I* won't take responsibility for fixing PL/Java when >I break it, because I don't know Java well enough. I don't know what >other people who do core development feel about that --- but I dislike >the idea that when someone changes such an API, the buildfarm will go >all red because there's only one person with the ability to fix PL/Java. > > > I take your point. I do have some java-fu, but I don't know how many other committers do, for example. The sad truth is that an effort to be absolutely fair and treat everyone the same may result in some PLs being worse off without any getting better off. I don't think we should aim at a Pareto disimprovement. Has it worked well in the case of client libraries? I am not sure it has. One thing is for sure, we need to do some proselytizing among packagers to make sure they pick up more than just what is in core. cheers andrew
mark@mark.mielke.cc wrote: > On the subject of 38K lines of code, much that isn't C (going by memory, > I apologize if this is wrong), how many of these lines could be/should be > shared between PL/Java and PL/J? It seems to me that the general concepts > should be in common, and that it is only how the Java interfaces with the > backend that changes. Could they not be one PL, with two mechanisms for > speaking to the backend? > By all means. An embedded JVM solution should share as much as possible with one that uses a remote JVM. From the users perspective there should be no difference at all. PL/Java is designed with this in mind. The class loader and the utility commands are based on JDBC, the security manager that enables the choice of trusted/untrusted execution is Java standard. A set of interfaces for non-standard access (PostgreSQL TriggerData in particular) was abstracted in order to allow different implementations. Etc. That said, there is also code that deals with tight backend integration and is highly specialized to fit the embedded solution. This code is designed around the fact that function calls to the backend are very cheap. As an example, PL/Java contains a JDBC driver that is written directly on top of the SPI API. The involved C-structures are rarely copied or streamed. They are accessed directly using JNI functions. I've spent some time lately, investigating what it would take to complement PL/Java with a remote JVM option. The major challenge lays in the impedance mismatch caused by concerns that one must consider when using RPC (limit the number of calls) compared to the current design (avoid copying and streaming). Kind regards, Thomas Hallgren
> No matter what we want people to do, if someone wants PostgreSQL, they > go to PostgreSQL's site, download PostgreSQL, and install PostgreSQL. > The fact is, most people generally don't read the, "don't see it in > the distribution, check out pgfoundry"-like text. Sure, people should > read the docs, but most don't until they have to (which is long after > getting the software). Do we even have anything in the actual manual > that talks about gborg or pgfoundry? Ahh no. Most people who want PostgreSQL use the version supplied by their vendor, unless it is Win32 in which case they download the installer from PgFoundry. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On 13-Jul-06, at 1:02 PM, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: >> I also cannot maintain Java, but we could do something like we do >> with >> WIN32, where outside folks submit patches to fix problems. > > However, a win32 failure breaks only the win32 buildfarm members ... > > Basically my point here is that I see no synergy from having PL/Java > (or PL/J for that matter) in core. They can't share the same > configure > or build support as the rest of the code; the core developers don't > feel > qualified to maintain them; what's left? > > The argument in favor boils down to one and only one thing: bundling > PL/Java will improve the visibility of PL/Java to people who won't go > looking for it. That's fine, but ultimately that's a packaging > argument > not a development argument. The people who think PL/Java is an > essential checklist item undoubtedly also think JDBC is an essential > checklist item, but I'm not seeing any groundswell of support for > putting JDBC back into core. Well, if this discussion ends up in a java project getting into core then there would be no reason whatsoever not to include JDBC. It's certainly more germane to the project than the java pl's > Instead we expect packagers (like the RPM > set) to make JDBC available alongside the core postgres packages. > That's how PL/Java ought to be handled, too, IMHO. > > In my own experience dealing with the Red Hat RPMs, it got a whole lot > easier to package JDBC correctly once it wasn't mis-bundled into a > basically non-Java source tarball, so I think that the packagers will > also find that keeping it separate makes their lives easier. > > regards, tom lane > Regards, Dave
Taking a step back here, I see two points in favor of including PL/Java or something like it into the main CVS: 1. Build farm support It seems that eventually one would like to have build farm support for many things. I can see build farm support being useful for the ODBC driver or Postgis, for instance. We need a better, more general solution for that. 2. Help with PL API changes On the one hand, that seems great, but on the other hand, I see a lot of people disqualifying themselves from touching PL/Java code in any significant way because they don't know Java well enough. So I don't see this working in practice. Or at least, it's quite doubtful that the convenience gained in this area will outweigh any inconveniences coming from this move. -- Peter Eisentraut http://developer.postgresql.org/~petere/
"Jonah H. Harris" <jonah.harris@gmail.com> writes:
> I don't believe anyone has offered any suggestions or good
> alternatives other than what we have now; keeping high-profile
> projects like PL/Java on gborg/pgfoundry (which sucks IMHO).
This is really the whole issue right here: you want a monolithic "core"
distribution. I cannot begin to list the number of things wrong with
that approach, but suffice it to say that that's not the way PostgreSQL
is moving. We are getting larger and we need to cater to having lots of
sub-projects. A "core" distro containing everything that's reasonably
popular will eventually collapse of its own weight.
The right way to proceed is what was mentioned in another message: work
harder at educating packagers about which non-core projects are worth
including in their packages. I have to confess contributing to the
problem, as I'm not currently including eg. Slony in the Red Hat RPMs.
I certainly should be --- but "fixing" that by pushing Slony into the
core PG distro is not a solution.
regards, tom lane
> From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of > Peter Eisentraut > > Taking a step back here, I see two points in favor of > including PL/Java or > something like it into the main CVS: > > 1. Build farm support > > It seems that eventually one would like to have build farm > support for many > things. I can see build farm support being useful for the > ODBC driver or > Postgis, for instance. We need a better, more general > solution for that. Does PL/Java really have to be in core to be tested in the build farm? Could the build farm code be enhanced to test non-core stuff? (I like the idea of a separate status 'light' for non-core.) > > 2. Help with PL API changes > > On the one hand, that seems great, but on the other hand, I > see a lot of > people disqualifying themselves from touching PL/Java code in > any significant > way because they don't know Java well enough. So I don't see > this working in > practice. Or at least, it's quite doubtful that the > convenience gained in > this area will outweigh any inconveniences coming from this move. > I think that if the buildfarm could alert us that there's a problem with a PL when it happens, rather than discovering it way later, having the code in the core repository is less critical. Regarding the packagers who don't include non-core components that their users might like, would a README.distros help? It could suggest good things to include, where to find them, and tips for building. This could also distinguish the mature packages on pgFoundry from the ones that are not quite ready for prime time: when a package's maintainer(s) think it's ready for production, they could submit a patch to the README.distros that adds the package. (I'm not attached to the filename, it just seemed less confusing than README.packagers.) Regards, Paul
-----Original Message----- From: "Jonah H. Harris" <jonah.harris@gmail.com> To: "Josh Berkus" <josh@agliodbs.com> Cc: "Thomas Hallgren" <thomas@tada.se>; "Dave Cramer" <pg@fastcrypt.com>; "David Fetter" <david@fetter.org>; "Satoshi Nagayasu"<nagayasus@nttdata.co.jp>; "Tom Lane" <tgl@sss.pgh.pa.us>; "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org> Sent: 13/07/06 14:43 Subject: Re: [HACKERS] Three weeks left until feature freeze > As for the JVM worries, it's perfectly fine for anyone to ship the > JVM. If we wanted to include the JVM in official PostgreSQL > distributions, we can do so. Otherwise, we can just rely on the user > to have a JVM installed. Which is exactly what we already do on Windows (we've bundled pl/java since 8.1) /D
Andrew Dunstan wrote: > Tom Lane wrote: > >> Dave Cramer <pg@fastcrypt.com> writes: >> >> >>> The official JDBC driver is not being shipped with the project for >>> exactly the same reasons, I fail to see any compelling reason to >>> ship either java PL. >>> >> >> >> >>> Unless we are going to create a complete distribution with a unified >>> build, or at least a way to build each project (which I am in favour >>> of) then we leave the server to itself and all other projects exist >>> separately. >>> > One thing is for sure, we need to do some proselytizing among packagers > to make sure they pick up more than just what is in core. What packagers? Every packager I see (Ubuntu, Fedora, *BSD, even Solaris) contain just about every conceivable package there is for PostgreSQL :) O.k. not every, but all of the really important stuff. Joshua D. Drake > > cheers > > andrew > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Thu, Jul 13, 2006 at 01:02:16PM -0400, Tom Lane wrote:
> PL/Java will improve the visibility of PL/Java to people who won't go
> looking for it. That's fine, but ultimately that's a packaging argument
> not a development argument. The people who think PL/Java is an
> essential checklist item undoubtedly also think JDBC is an essential
> checklist item, but I'm not seeing any groundswell of support for
> putting JDBC back into core. Instead we expect packagers (like the RPM
> set) to make JDBC available alongside the core postgres packages.
> That's how PL/Java ought to be handled, too, IMHO.
JDBC is different, in that it doesn't require the PostgreSQL core to
build. It's 100% native Java, and as such, I see benefit to it being
distributed separately.
This is why I was thinking that the problem is that the backend (SPI?)
API isn't exposed as native methods in the required languages. If just
the SPI API was exposed from the core to the languages, the
maintenance effort and size should be less, and the add-ons would not
require that they be built with the PostgreSQL core, making it easy to
integrate them after the fact.
If this is just crazy talk - please stop me.
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness
bindthem...
http://mark.mielke.cc/
* Joshua D. Drake (jd@commandprompt.com) wrote:
> Csaba Nagy wrote:
> >On Thu, 2006-07-13 at 15:29, Stephen Frost wrote:
> >>It's not the PostgreSQL project's problem, that's true, but it certainly
> >>becomes an issue for distributions. Java as a PL ends up being a pretty
> >>odd case.. If there isn't anything in the PL code itself which forces a
> >>dependency beyond gcj then it might be possible to distribute it. Also
> >>allowing the PL to use a different JVM shouldn't be a problem so long as
> >>nothing is distributed which depends on the alternate JVM. The GPL is
> >>all about distribution and so I'm not sure that it would actually be a
> >>problem for an end-user to use Sun's JVM with GPL'd Java code.
> >
> >Now I'm completely confused... what GPL code ? Is PL/Java licensed under
> >the GPL ? Or what GPL code do you talk about ?
>
> What was a mistake on my part. I was tired when I wrote the part about GPL.
As for my part, I was referring to any GPL'd Java code being distributed
with a given distribution (ie: Debian), possibly running under PL/Java.
:)
Thanks,
Stephen
Bruce, On 7/7/06 10:13 AM, "Bruce Momjian" <bruce@momjian.us> wrote: > There are roughly three weeks left until the feature freeze on August 1. > If people are working on items, they should be announced before August > 1, and the patches submitted by August 1. If the patch is large, it > should be discussed now and an intermediate patch posted to the lists > soon. On-disk bitmap index access method coming in about 1 week. Multi-column index support is being worked more and will be disabled in the patch first submitted, but could be enabled before code freeze. There is a new directory for the access method and some changes to the executor nodes that currently do bitmap operations, so brace for a large-ish chunk of code. Do we have a reviewer available? Volunteers? - Luke
mark@mark.mielke.cc wrote: > >This is why I was thinking that the problem is that the backend (SPI?) >API isn't exposed as native methods in the required languages. If just >the SPI API was exposed from the core to the languages, the >maintenance effort and size should be less, and the add-ons would not >require that they be built with the PostgreSQL core, making it easy to >integrate them after the fact. > > > The glue code needs much more than SPI. There is a lot of housekeeping involved. cheers andrew
On Thu, Jul 13, 2006 at 01:26:30PM -0400, Tom Lane wrote: > The right way to proceed is what was mentioned in another message: work > harder at educating packagers about which non-core projects are worth > including in their packages. I have to confess contributing to the > problem, as I'm not currently including eg. Slony in the Red Hat RPMs. > I certainly should be --- but "fixing" that by pushing Slony into the > core PG distro is not a solution. Indeed. Distributors are not going to go through pgfoundary and package everything, there's just no point. I think it would be very useful to dedicate a portion of the website to add-ons that are considered worthwhile. "considered worthwhile by who" becomes the big question then. PgFoundary has a "Top Project Downloads" section. That gives a pretty good indication of the things that should be advertised. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
On 7/13/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > This is really the whole issue right here: you want a monolithic "core" > distribution. I cannot begin to list the number of things wrong with > that approach, but suffice it to say that that's not the way PostgreSQL > is moving. I'm not going to argue at all and will gladly second Josh's statement.If the core doesn't want to include it, commercialcompanies (EnterpriseDB, Command Prompt, ...) and consultants will continue to do it for us. I mean, why should we make it easier for the end-user? Especially when we know there are certain components that practically every database user needs (ODBC, JDBC, etc.) > We are getting larger and we need to cater to having lots of > sub-projects. A "core" distro containing everything that's reasonably > popular will eventually collapse of its own weight. I don't think we should include everything, and I belive that "collapse" is debatable. The important part is how the distro itself is managed. One can easily create a "core" distribution which includes PL/Java, ODBC, JDBC, etc. All of them don't have to reside in the same CVS tree, but they can be built and released together. I know because I've done it... and it's not that difficult. The hard part is actually deciding what to include and what not to. In general, we're talking about well established projects (PL/Java, JDBC, ODBC, ...) with a great track record; not someone's personal little proof-of-concept hack on pgfoundry. Like I said, this discussion always seems to come up and we always go back to saying "leave it to pgfoundry", "we'll promote pgfoundry", "pgfoundry is the best place for it". Yet, I haven't really seen any action to make pgfoundry any better or more well-known. I asked before, is pgfoundry/gborg even mentioned in the documentation? > The right way to proceed is what was mentioned in another > message: work harder at educating packagers about which > non-core projects are worth including in their packages. OK, but who is going to do this? It certainly doesn't sound like any of us want to spend the time educating packagers as we're either working on our own things or for companies that already do package PostgreSQL. It just seems like we keep having lengthy recurring discussions that seem to go nowhere. No solution is ever reached, we just keep the status quo. Sure, risks either pay off or they don't, but it's just as easy to die from stagnation as well. I wish we could poll the actual end-users and see what their thoughts are, because we're sort of thinking in a vacuum here (no pun intended). I can readily accept being wrong; but every once in a while, we just need a little innovation. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
mark@mark.mielke.cc writes:
> This is why I was thinking that the problem is that the backend (SPI?)
> API isn't exposed as native methods in the required languages. If just
> the SPI API was exposed from the core to the languages, the
> maintenance effort and size should be less, and the add-ons would not
> require that they be built with the PostgreSQL core, making it easy to
> integrate them after the fact.
It's not just SPI --- SPI for instance doesn't deal at all with the
problem of how you create a language call handler function. SPI was
never intended to be a "complete" API, but rather something easy to
use that covers most cases of C code needing to invoke SQL queries.
Code that's trying to offer features to SQL is entirely orthogonal
to what SPI is about.
I'm not real sure what a feature-complete API for language handlers
might look like, but it'd cover far more than SPI does. And this
really just begs the question: could we afford to promise a frozen
API that *is* feature-complete at that level? The changes we've made
recently that affected both core and PLs have mostly been things like
adding OUT parameter support, which certainly would have involved
changing a language handler API; or modifications to the system
catalogs, which I can't see a handler API masking; or changes to the
conventions for passing tuples as Datums, which again I doubt an API
would have successfully hidden.
It's an interesting idea to think about, but I think any solution
of this kind is a long way off, unless the internals of the backend
suddenly become a lot more stable than they have been in the past.
regards, tom lane
Tom Lane wrote: >The right way to proceed is what was mentioned in another message: work >harder at educating packagers about which non-core projects are worth >including in their packages. I have to confess contributing to the >problem, as I'm not currently including eg. Slony in the Red Hat RPMs. >I certainly should be --- but "fixing" that by pushing Slony into the >core PG distro is not a solution. > > > Well, there are other good reasons not to in the slony case. But anyway, I was wondering if we could make life easier by providing a script which would fetch some set of addon features, and make building the whole lot together easy. No doubt some people will not want to make choices, but I think we need to, to some extent. I broadly agree with what Martijn has just said, although I doubt that pgFoundry's Top Downloads section is much of a guide. If we recommend something we need to be prepared to exerciase some jusgement and have the courage of our convictions. Personally, I would start with: pl/java pl/ruby pl/php jdbc driver odbc driver npgsql python stuff (not sure which, as I don't use it) The perl and php clients, and libpqxx would also be possibilities. cheers andrew
mark@mark.mielke.cc wrote: > On Thu, Jul 13, 2006 at 01:02:16PM -0400, Tom Lane wrote: >> PL/Java will improve the visibility of PL/Java to people who won't go >> looking for it. That's fine, but ultimately that's a packaging argument >> not a development argument. The people who think PL/Java is an >> essential checklist item undoubtedly also think JDBC is an essential >> checklist item, but I'm not seeing any groundswell of support for >> putting JDBC back into core. Instead we expect packagers (like the RPM >> set) to make JDBC available alongside the core postgres packages. >> That's how PL/Java ought to be handled, too, IMHO. > > JDBC is different, in that it doesn't require the PostgreSQL core to > build. It's 100% native Java, and as such, I see benefit to it being > distributed separately. PLJava does not need PostgreSQL core to build either. It needs: pgxs + Postgresql libs + PostgreSQL headers In essence the PostgreSQL SDK. If I read what Thomas wrote (late) last night correctly. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Thu, 13 Jul 2006, Jonah H. Harris wrote: > I don't believe anyone has offered any suggestions or good alternatives > other than what we have now; keeping high-profile projects like PL/Java > on gborg/pgfoundry (which sucks IMHO). Why? What is being discussed here is *purely* a packaging issue ... how many actually download the postgresql tar ball directly, vs downloading RPMs, or installing from FreeBSD ports, or Solaris packages, or ... ? Using pl/Java as an example ... just went to Google, searched for pl<space>java, and gborg comes up as the first response, so finding it isn't difficult ... But, I can't find anything there to download ... just a pointer to a Wiki, which, I'm sorry, would definitely not be my first thought to go look at for a downloads ... So, let's try ftp ... ftp.postgresql.org:/pub/projects/gborg/pljava/stable: Nothing there newer then November 2005: ftp> ls -lt 227 Entering Passive Mode (66,98,251,159,248,251) 150 Opening ASCII mode data connection for /bin/ls. total 23026 -rw-r--r-- 1 80 1009 206134 Nov 20 2005 pljava-src-1.2.0.tar.gz -rw-r--r-- 1 80 1009 522895 Nov 20 2005 pljava-i686-pc-mingw32-pg8.1-1.2.0.tar.gz -rw-r--r-- 1 80 1009 522955 Nov 20 2005 pljava-i686-pc-mingw32-pg8.0-1.2.0.tar.gz -rw-r--r-- 1 80 1009 421717 Nov 20 2005 pljava-i686-pc-linux-gnu-pg8.1-1.2.0.tar.gz -rw-r--r-- 1 80 1009 421999 Nov 20 2005 pljava-i686-pc-linux-gnu-pg8.0-1.2.0.tar.gz so, if there is a newer version (I actually eventually went to the wiki, so know there is a 1.3.0), its not taking advantage of the PostgreSQL file distribution network that has been developed over the years ... 'k, go back and check Google, the top 5 listings, in order: gborg x 2 pl-j pgfoundry pljava wiki so, if using google, the first place most ppl will go to look for informatino is the one place you say "sucks" ... gborg ... second choice would be the other place you say "sucks" ... pgfoundry ... eventually, giving up on those two, they'd maybe try the wiki, *but*, only because the project maintainer hasn't been uploading files to gborg/pgfoundry, not because gborg/pgfoundry isn't found in search engines ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Thu, 13 Jul 2006, Jonah H. Harris wrote: > On 7/13/06, Lukas Smith wrote: >> However I do think that PostgreSQL is missing out in >> getting new users aboard that are in the early stages >> of evalutation and simply only consider features that >> they get along with a default installation (mostly due >> to lack of better knowledge about places like pgfoundry). > > This is my point exactly. As with many things, we keep skirting the > real issue by going with an "improve the smaller component" approach > such as "promote pgfoundry more". I have never seen this approach > work, but maybe someone has an example of another OSS project that has > successfully excluded major components like this? Major component for whom exactly? What %age of PostgreSQL users are using pl/Java? Are using Java, period? There is only one *major component* and that is the RDBMS itself ... everything else is an add on specific to each end users requirements ... in all of my years of hosting PostgreSQL-backed web sites, I've *never* had a request for a PL/J* ... lots for JDBC, mind you, just never for the PLs ... So, do you have some sort of #s as to why pl/Java is such a 'major component'? I'd see pl/Perl and pl/PHP as been alot more major ... > My question is, what is the packagers' stance on this topic? It seems > like more work for them than for anyone else. Why more work for them? CommandPrompt developed pl/PHP in such a way that it doesn't require the PostgreSQL source code at all ... so, a packager coudl go out, get a binary (rpm?) distro of PostgreSQL, install that and then build their pl/PHP package, without ever having to touch the postgresql source code ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On 7/13/06, Marc G. Fournier <scrappy@postgresql.org> wrote: > Why? Because, the fact is that it's a PITA and many people don't even go far enough to look. If major components of PostgreSQL were included in the core, it would make it much easier for people; especially those familiar with commercial-class database systems. > What is being discussed here is *purely* a packaging issue Pretty much. > Using pl/Java as an example ... just went to Google, searched for > pl<space>java, and gborg comes up as the first response, so finding it > isn't difficult ... Never said it was... but then again, you already know about it. > But, I can't find anything there to download ... just a pointer to a Wiki, > which, I'm sorry, would definitely not be my first thought to go look at > for a downloads ... Hmm, yes... just saw that and it is a bit odd. Thomas, I like the layout of the Wiki... but could we move the project files to pgfoundry for hosting and set the project's home page as the wiki? -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On Thu, 13 Jul 2006, Jonah H. Harris wrote: > Aside from obviously the big issue of who maintains all the pgfoundry > stuff, I also think that the PostgreSQL family would benefit from a > distribution that is more "and the kitchen sink" style. This has been suggested before ... nobody seems to want to 'run with it'/coordinate it though ... maybe that, in itself, is argument enough against doing it, only a small number of ppl *really* care/want it, and those ones aren't willing to put forth the energy required to do it ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
> I don't think we should include everything, and I belive that > "collapse" is debatable. The important part is how the distro itself > is managed. One can easily create a "core" distribution which > includes PL/Java, ODBC, JDBC, etc. All of them don't have to reside > in the same CVS tree, but they can be built and released together. I > know because I've done it... and it's not that difficult. The hard > part is actually deciding what to include and what not to. And people already do this... The Win32 installer mammothpostgresql.org (which is 100% FOSS btw) Ubuntu :) So why put the load on the Core distro? > In general, we're talking about well established projects (PL/Java, > JDBC, ODBC, ...) with a great track record; not someone's personal > little proof-of-concept hack on pgfoundry. Well define great track record? Of the three you mention, two of them are debatable. PL/java although from what I can tell is stable but it is still young. ODBC is a constant problem, I didn't even realize what level of problem ODBC could be until we wrote our own driver (READ: I am not blaming the ODBC team) > Like I said, this discussion always seems to come up and we always go > back to saying "leave it to pgfoundry", "we'll promote pgfoundry", > "pgfoundry is the best place for it". Yet, I haven't really seen any > action to make pgfoundry any better or more well-known. I asked > before, is pgfoundry/gborg even mentioned in the documentation? It is on the website and in the documentation. Albeit not as prominent as it could be. And to be frank, the amount of time any of us has spent on this thread could have easily been used to improve the documentation on this particular subject. >> The right way to proceed is what was mentioned in another >> message: work harder at educating packagers about which >> non-core projects are worth including in their packages. > > OK, but who is going to do this? It certainly doesn't sound like any > of us want to spend the time educating packagers as we're either > working on our own things or for companies that already do package > PostgreSQL. Well honestly this seems like a no-op. The distributions that really matter, are going to have packagers that know what is out there. Ubuntu/Debian and FreeBSD come to mind first. > It just seems like we keep having lengthy recurring discussions that > seem to go nowhere. No solution is ever reached, we just keep the > status quo. Sure, risks either pay off or they don't, but it's just > as easy to die from stagnation as well. Haha :) Welcome to FOSS development man :). It is 75% discussions that go nowhere, 20% percent that get somewhere (noone actually knows where) and 5% that gets done :) > I wish we could poll the actual end-users and see what their thoughts > are, because we're sort of thinking in a vacuum here (no pun > intended). Well my users expect me to provide their tools, not the community. In fact that is one of the most oft questions I get asked: "If we want to help PostgreSQL, will you handle it for us". > > I can readily accept being wrong; but every once in a while, we just > need a little innovation. > I don't think innovation is the word your looking for, progress maybe? The problem is, progress is determined by arbitrary value to which everyone has an opinion. I mean heck... I still think we should introduce new features into back branches as long as it doesn't require an initdb but most (including my own developers) don't agree with me. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Thu, 13 Jul 2006, Jonah H. Harris wrote: > On 7/13/06, Dave Cramer <pg@fastcrypt.com> wrote: >> The official JDBC driver is not being shipped with the project for >> exactly the same reasons, I fail to see any compelling reason to ship >> either java PL. > > IMHO, we should be shipping the JDBC driver... but that's another > matter entirely. Again, that goes to your 'kitchen sink distribution' ... its been suggested many times before, nobody cared enough to run with the idea and do something about it ... do you? > When someone downloads the PostgreSQL server on Windows... we know > they're probably going to be using ODBC... so we should ship it; but > which one? How do we determine which one as a community? that's a packaging issue ... the Windows Installer can (does?) pull that in as part of its install, or, at least, packaging stage, as it does other things ... > Eventually we need to evolve a little bit and tackle these types of > issues; I don't think gborg or pgfoundry are the best places for > high-profile, commonly used PostgreSQL drivers, PLs, or functions. Commonly used by whom? a pl/PHP user is most likely not going to ever use pl/Perl, or any other pl ... so, which are "commonly used" and which are used by a "small set of ppl"? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Thu, 13 Jul 2006, Rod Taylor wrote: > A slight restructuring of the FTP tree should probably be made. It's > currently very easy to find the main pgsql, pgadmin and odbc components. > Finding pl/java (what the heck is that gborg or pgfoundry project?) is > pretty difficult. The gborg vs pgfoundry issue is being worked on, albeit slowly ... gborg is being 'sucked into' pgfoundry, but with OSCON and the Conference, and summer holidays, things have slowed down a bit .... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Thu, 13 Jul 2006, Joshua D. Drake wrote: > >> I don't think we should include everything, and I belive that >> "collapse" is debatable. The important part is how the distro itself >> is managed. One can easily create a "core" distribution which >> includes PL/Java, ODBC, JDBC, etc. All of them don't have to reside >> in the same CVS tree, but they can be built and released together. I >> know because I've done it... and it's not that difficult. The hard >> part is actually deciding what to include and what not to. > > > And people already do this... > > The Win32 installer > mammothpostgresql.org (which is 100% FOSS btw) > Ubuntu :) > > So why put the load on the Core distro? Agreed ... but, maybe on our FTP/download pages, we should add a link for 'Distributions', that would include mammothpostgresql.org and Ubuntu? so that ppl knew about them? We do it for support related stuff ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On 7/13/06, Marc G. Fournier <scrappy@postgresql.org> wrote: > Major component for whom exactly? What %age of PostgreSQL > users are using pl/Java? Are using Java, period? Got me, but I don't think you have the facts to dispute it either. As I said, we're discussing this in a vacuum. > There is only one *major component* and that is the RDBMS itself ... > everything else is an add on specific to each end users requirements Hmm, connecting to the database is an end-user requirement. That's why every database vendor in the world has an ODBC and JDBC driver... and why most of them ship it with the server? > in all of my years of hosting PostgreSQL-backed web sites, I've *never* > had a request for a PL/J* ... lots for JDBC, mind you, just never for the > PLs ... Interesting > Why more work for them? CommandPrompt developed pl/PHP > in such a way that it doesn't require the PostgreSQL source code > at all ... so, a packager coudl go out, get a binary (rpm?) distro > of PostgreSQL, install that and then build their pl/PHP package, > without ever having to touch the postgresql source code ... Again, you and I are PostgreSQL people. Arguing with me about how easy it is to do X and Y is pointless. I'm talking about someone new to PostgreSQL... AFAICS, we have *never* been looking to help them which I believe is another reason for lesser adoption. I'm not trying to be pessimistic, but this reminds me of that Ubergeek Flash animation with the Linux SuperVillian (http://www.ubergeek.tv/article.php?pid=54): Excerpt (regarding Linux): You've got to config it. And then you have to write some shell scripts. Update your RPMs. You have to partition your drives. And patch your kernel. Compile your binaries. Check your version dependencies. Probably do that once or twice. It's just so easy. And so simple. I don't know why everyone doesn't run Linux. Thank God they don't, or then they would all be supervillains, wouldn't they? Heh heh. Sounds kinda like our discussions: You've got to download it. And then you have to go check the website. Download some drivers and PLs. You have to check your version dependencies. Compile your binaries and/or install them. Probably do that once or twice. It's just so easy. And so simple. I don't know why everyone doesn't use PostgreSQL. Thank God they don't, or then they would all be supervillains, wouldn't they? Heh heh. Look, we all love PostgreSQL and we all want to see it do better; otherwise we wouldn't be here. As a community, we all have some influence in the project as well as a stake in what happens. Rather than geting all defensive, we need to find out what people who are using PostgreSQL want so we can make a distribution and/or recommendation to packagers. Again, the arguments made here only apply to current users, when we *should* be thinking about what new users as well as current users would benefit from. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On 7/13/06, Marc G. Fournier <scrappy@postgresql.org> wrote: > Again, that goes to your 'kitchen sink distribution' ... its been > suggested many times before, nobody cared enough to run > with the idea and do something about it ... do you? I certainly care, but I don't have the time. Which, I know, is the case with most of us. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On Thu, 13 Jul 2006, Jonah H. Harris wrote: > Sounds kinda like our discussions: > You've got to download it. And then you have to go check the website. > Download some drivers and PLs. You have to check your version > dependencies. Compile your binaries and/or install them. Probably do > that once or twice. It's just so easy. And so simple. I don't know > why everyone doesn't use PostgreSQL. Thank God they don't, or then > they would all be supervillains, wouldn't they? Heh heh. 'k, but, again, this comes to someone (you?) stepping forward and dedicating the time/energy to developing a 'mega distribution', and being willing to provide support for it ... see, as soon as you incorporate all of this as one big package, then ppl will turn to the maintainer of that 'mega package' for their support needs, cause they won't know that pl/Java is maintained by Thomas Hallgren, or that pl/PHP is maintained by CommandPrompt, or that ... But, again, its not a *core* distribution issue, it is a packaging issue ... And note that I didn't include 'resources' in the above 'time/energy', as you *can* use pgfoundry for that ... Heck, why not building a Unix Installer like the Windows one, bring up a menu with a list of options to install, and pull in what is needed, instead of forcing it all on someone? Neat thing about that: you could then maintain statistics on what ppl are actually downloading ... But, as JD pointed out earlier ... there is mammothpostgresql.org already, which is apparently FOSS, so instead of "yet another distribution" maybe look into extending that, add an Installation interface over top of it (if it doesn't already exist), etc ... ? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Thu, 13 Jul 2006, Joshua D. Drake wrote: > >> Aside from obviously the big issue of who maintains all the pgfoundry >> stuff, I also think that the PostgreSQL family would benefit from a >> distribution that is more "and the kitchen sink" style. I do not know >> exactly if Bizgres could be considered just that? Or maybe it could get >> promoted to be that? > > Lukas, that is what www.mammothpostgresql.org is :) Then *it* needs to be promoted more, since this is actually the first I'd heard of it :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
"Jonah H. Harris" <jonah.harris@gmail.com> writes: > On 7/13/06, Marc G. Fournier <scrappy@postgresql.org> wrote: >> Why? > Because, the fact is that it's a PITA and many people don't even go > far enough to look. If major components of PostgreSQL were included > in the core, it would make it much easier for people; especially those > familiar with commercial-class database systems. No, the correct way to say that is "if major components were included in the readily-available distributions of Postgres" then newbies would find it easier to find them. That doesn't lead to concluding that we should redefine "core" as "everything that's popular". These days I don't believe that many newbies download and compile the core PG source distribution --- newbies are using the Windows installer or pre-packaged Linux distributions, and so the right answer is to make sure that those packagers provide all the important add-ons nearby to the core packages. For those who are actually downloading stuff directly from http://www.postgresql.org/download/, that page already does list most of the add-ons that have been mentioned in this thread. Perhaps we need to adjust the wording to make it clearer that you probably want some of them. One really trivial change is that the second sentence says "full package" where it ought to say "core package" --- we should consistently reinforce the idea that you're getting a database core, not everything that you might want to go with it. regards, tom lane
On 7/13/06, Marc G. Fournier <scrappy@postgresql.org> wrote: > 'k, but, again, this comes to someone (you?) stepping forward and > dedicating the time/energy to developing a 'mega distribution', and being > willing to provide support for it True. Then maybe we should just all work together to make a distribution suggestion to packagers of the major components and their versions. That way the packagers at least have a good idea of what we believe is "good-to-go" with X version of PostgreSQL. > Heck, why not building a Unix Installer like the Windows one, bring up a > menu with a list of options to install, and pull in what is needed, > instead of forcing it all on someone? Neat thing about that: you could > then maintain statistics on what ppl are actually downloading ... Yes, I very much like this idea. > But, as JD pointed out earlier ... there is mammothpostgresql.org already, > which is apparently FOSS, so instead of "yet another distribution" maybe > look into extending that, add an Installation interface over top of it (if > it doesn't already exist), etc ... ? Not to be too "business" about it, but a PostgreSQL community distribution should IMHO, be vendor neutral. If the installer were vendor-branding-free, I'd be game. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
-----Original Message----- From: "Marc G. Fournier" <scrappy@postgresql.org> To: "Rod Taylor" <pg@rbt.ca> Cc: "Jonah H. Harris" <jonah.harris@gmail.com>; "postgres hackers" <pgsql-hackers@postgresql.org> Sent: 13/07/06 20:06 Subject: Re: [HACKERS] Three weeks left until feature freeze > The gborg vs pgfoundry issue is being worked on, albeit slowly ... gborg > is being 'sucked into' pgfoundry, but with OSCON and the Conference, and > summer holidays, things have slowed down a bit .... Actually, the conference has helped with that - Larry & I hashed out a plan which he's getting started on, so hopefully we'llsoon start killing dead projects, and migrating others. /D
On Thu, 13 Jul 2006, Joshua D. Drake wrote: > >> No matter what we want people to do, if someone wants PostgreSQL, they >> go to PostgreSQL's site, download PostgreSQL, and install PostgreSQL. >> The fact is, most people generally don't read the, "don't see it in >> the distribution, check out pgfoundry"-like text. Sure, people should >> read the docs, but most don't until they have to (which is long after >> getting the software). Do we even have anything in the actual manual >> that talks about gborg or pgfoundry? > > Ahh no. > > Most people who want PostgreSQL use the version supplied by their vendor, > unless it is Win32 in which case they download the installer from PgFoundry. Agreed ... I never download from ftp unless I need an older version then is provided in FreeBSD ports ... and I have a few clients that won't even *touch* the source code, but will only install the version that their OS vendor provides, for support reasons ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On 7/13/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > No, the correct way to say that is "if major components were included in > the readily-available distributions of Postgres" then newbies would find > it easier to find them. OK, I agree. Damn semantics :) > That doesn't lead to concluding that we should redefine "core" > as "everything that's popular". Alright, but I believe we should at least work together when planning a release to make a set recommendation to packagers. > These days I don't believe that many newbies download and > compile the core PG source distribution Totally agreed. I have been meaning that our packages (non-src) should have common tools with them. > For those who are actually downloading stuff directly from > http://www.postgresql.org/download/, that page already does list most > of the add-ons that have been mentioned in this thread. > Perhaps we need to adjust the wording to make it clearer ... Yes, that would probably help some. > One really trivial change is that the second sentence says "full > package" where it ought to say "core package" --- we should consistently > reinforce the idea that you're getting a database core, not everything > that you might want to go with it. Agreed. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
> Major component for whom exactly? What %age of PostgreSQL users are > using pl/Java? Are using Java, period? > > There is only one *major component* and that is the RDBMS itself ... > everything else is an add on specific to each end users requirements ... > in all of my years of hosting PostgreSQL-backed web sites, I've *never* > had a request for a PL/J* ... lots for JDBC, mind you, just never for > the PLs ... > > So, do you have some sort of #s as to why pl/Java is such a 'major > component'? I'd see pl/Perl and pl/PHP as been alot more major ... I know I am going to regret this but: pl/Java is a MAJOR component. In one place. The Enterprise. Otherwise it really isn't. A spot poll of businesses will show quite readily that most are running, PHP, Perl, Ruby, Python... and unfortunately VB. However, for the most part NOT if they are an Enterprise. It is also a major component in our battle against the big red O. However, all of this argument is moot. The only argument that really matters in this discussion is the one that Tom brought up. >> My question is, what is the packagers' stance on this topic? It seems >> like more work for them than for anyone else. > > Why more work for them? CommandPrompt developed pl/PHP in such a way > that it doesn't require the PostgreSQL source code at all ... so, a > packager coudl go out, get a binary (rpm?) distro of PostgreSQL, install > that and then build their pl/PHP package, without ever having to touch > the postgresql source code ... Yes and my understanding is that PLjava can do the same. Sincerely, Joshua D. Drake > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email . scrappy@hub.org MSN . scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Jonah H. Harris wrote: > On 7/13/06, Marc G. Fournier <scrappy@postgresql.org> wrote: >> Why? > > Because, the fact is that it's a PITA and many people don't even go > far enough to look. If major components of PostgreSQL were included > in the core, it would make it much easier for people; especially those > familiar with commercial-class database systems. Uhmmm that is what CMD and EDB are supposed to be doing. Educating their customers, gaining more customers and educating them. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Marc G. Fournier wrote: > On Thu, 13 Jul 2006, Jonah H. Harris wrote: > >> Aside from obviously the big issue of who maintains all the pgfoundry >> stuff, I also think that the PostgreSQL family would benefit from a >> distribution that is more "and the kitchen sink" style. > > This has been suggested before ... nobody seems to want to 'run with > it'/coordinate it though ... maybe that, in itself, is argument enough > against doing it, only a small number of ppl *really* care/want it, and > those ones aren't willing to put forth the energy required to do it ... I repeat: www.mammothpostgresql.org :) Joshua D. Drake > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email . scrappy@hub.org MSN . scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
>> So why put the load on the Core distro? > > Agreed ... but, maybe on our FTP/download pages, we should add a link > for 'Distributions', that would include mammothpostgresql.org and > Ubuntu? so that ppl knew about them? We do it for support related > stuff ... That is a great idea :) Joshua D. Drake > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email . scrappy@hub.org MSN . scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Marc G. Fournier wrote: > On Thu, 13 Jul 2006, Joshua D. Drake wrote: > >> >>> Aside from obviously the big issue of who maintains all the pgfoundry >>> stuff, I also think that the PostgreSQL family would benefit from a >>> distribution that is more "and the kitchen sink" style. I do not know >>> exactly if Bizgres could be considered just that? Or maybe it could get >>> promoted to be that? >> >> Lukas, that is what www.mammothpostgresql.org is :) > > Then *it* needs to be promoted more, since this is actually the first > I'd heard of it :( Were trying man :) I have people building for most major distributions at this point. We should have FreeBSD soon, as well as MacOSX. Sincerely, Joshua D. Drake > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email . scrappy@hub.org MSN . scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
> > Sounds kinda like our discussions: > You've got to download it. And then you have to go check the website. > Download some drivers and PLs. You have to check your version > dependencies. Compile your binaries and/or install them. Probably do > that once or twice. It's just so easy. And so simple. I don't know > why everyone doesn't use PostgreSQL. Thank God they don't, or then > they would all be supervillains, wouldn't they? Heh heh. Well this is more of a marketing thing. Who is our target? Oracle, DB2 and MSSQL users... or Access and MySQL? I will opt for the first thanks, and those people don't expect everything just to be right out of the box (o.k. maybe MSSQL does.) Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Mario Weilguni wrote: > Will this patch make it into 8.2? > http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php > > It's a really nice feature, would be extremly useful with tools like pgpool. No, it will not because RESET CONNECTION can mess up interface code that doesn't want the connection reset. We are not sure how to handle that. --------------------------------------------------------------------------- > > Am Freitag, 7. Juli 2006 19:13 schrieb Bruce Momjian: > > There are roughly three weeks left until the feature freeze on August 1. > > If people are working on items, they should be announced before August > > 1, and the patches submitted by August 1. If the patch is large, it > > should be discussed now and an intermediate patch posted to the lists > > soon. > > > > FYI, we don't have many major features ready for 8.2. > > > > -- > > Bruce Momjian bruce@momjian.us > > EnterpriseDB http://www.enterprisedb.com > > > > + If your life is a hard drive, Christ can be your backup. + > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 5: don't forget to increase your free space map settings > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
kleptog@svana.org (Martijn van Oosterhout) writes: > On Thu, Jul 13, 2006 at 01:26:30PM -0400, Tom Lane wrote: >> The right way to proceed is what was mentioned in another message: >> work harder at educating packagers about which non-core projects >> are worth including in their packages. I have to confess >> contributing to the problem, as I'm not currently including >> eg. Slony in the Red Hat RPMs. I certainly should be --- but >> "fixing" that by pushing Slony into the core PG distro is not a >> solution. > > Indeed. Distributors are not going to go through pgfoundary and > package everything, there's just no point. I think it would be very > useful to dedicate a portion of the website to add-ons that are > considered worthwhile. If there were enough chunks of it that were buildable using pgxs or similar such that they could pretty readily script up... for project in `echo $LIST`; do cd $DOWNLOADS wget http://downloads.pgfoundry.org/${project}/${project}-latest.tar.bz2 cd $BUILDHOME mkdir $${project} cd $${project} tarxfvj $DOWNLOADS/${project}-latest.tar.bz2 cd * ./configure --pgxs-options --path=/usr --rpm-deteriorata make install run-rpm-file-collector $${project} done The folks running Perl and Python repositories have gotten the "toolage" together so that you can pull CPAN packages and very nearly turn them into RPM packages. If we have an interestingly large set of packages at pgFoundry that are "that RPMable," then they *will* come. -- let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;; http://cbbrowne.com/info/oses.html Rules of the Evil Overlord #98. "If an attractive young couple enters my realm, I will carefully monitor their activities. If I find they are happy and affectionate, I will ignore them. However if circumstance have forced them together against their will and they spend all their time bickering and criticizing each other except during the intermittent occasions when they are saving each others' lives at which point there are hints of sexual tension, I will immediately order their execution." <http://www.eviloverlord.com/>
Marc G. Fournier wrote: > On Thu, 13 Jul 2006, Rod Taylor wrote: > > > A slight restructuring of the FTP tree should probably be made. It's > > currently very easy to find the main pgsql, pgadmin and odbc components. > > Finding pl/java (what the heck is that gborg or pgfoundry project?) is > > pretty difficult. > > The gborg vs pgfoundry issue is being worked on, albeit slowly ... gborg > is being 'sucked into' pgfoundry, but with OSCON and the Conference, and > summer holidays, things have slowed down a bit .... How can you slow from zero? ;-) -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Joshua D. Drake wrote: > >> Aside from obviously the big issue of who maintains all the pgfoundry >> stuff, I also think that the PostgreSQL family would benefit from a >> distribution that is more "and the kitchen sink" style. I do not know >> exactly if Bizgres could be considered just that? Or maybe it could get >> promoted to be that? > > Lukas, that is what www.mammothpostgresql.org is :) Doh, yes .. totaly forgot about that one. Again I think it makes absolute sense to have a nicely sized core for all the friendly forks to base their work on. However I think all newbie PR should be directed at the monolithic distro and not to that nicely sized core. Cluefull people that want to create their own PostgreSQL distro will naturally gravitate to PostgreSQL, while newbies come to PostgreSQL right now. They dont find the feature they are looking for, and we miss out on getting them into PostgreSQL. So what I am suggesting is that PostgreSQL.org should push people towards the monolithic distro. The docs should contain everything that is in the monolithic distro. At conference we should say the name of the monolithic distro etc. Again, the truely cluefull people will naturally gravitate to the PostgreSQL core project while the monolithic distro sucks in the newbies. regards, Lukas
On Thu, 13 Jul 2006, Lukas Smith wrote: > Joshua D. Drake wrote: >> >>> Aside from obviously the big issue of who maintains all the pgfoundry >>> stuff, I also think that the PostgreSQL family would benefit from a >>> distribution that is more "and the kitchen sink" style. I do not know >>> exactly if Bizgres could be considered just that? Or maybe it could get >>> promoted to be that? >> >> Lukas, that is what www.mammothpostgresql.org is :) > > Doh, yes .. totaly forgot about that one. > > Again I think it makes absolute sense to have a nicely sized core for all the > friendly forks to base their work on. However I think all newbie PR should be > directed at the monolithic distro and not to that nicely sized core. > > Cluefull people that want to create their own PostgreSQL distro will > naturally gravitate to PostgreSQL, while newbies come to PostgreSQL right > now. They dont find the feature they are looking for, and we miss out on > getting them into PostgreSQL. > > So what I am suggesting is that PostgreSQL.org should push people towards the > monolithic distro. The docs should contain everything that is in the > monolithic distro. At conference we should say the name of the monolithic > distro etc. > > Again, the truely cluefull people will naturally gravitate to the PostgreSQL > core project while the monolithic distro sucks in the newbies. But, that isn't our role ... that should be the role of whomever takes on the role of 'maintainer' for such a monolithic distribution ... its no more our role to decide that pl/Java is better or worse then pl/J ... our role is to provide that core for everyone else to build around ... People like CommandPrompt, Bizgres, EnterpriseDB, Pervasive ... they have the funding to *create* and maintain that, to make sure all the parts they distribute are working properly ... The resources are there, if someone (you?) wants to do this as a FOSS project, but I fear that amount of work (both time and energy) required to make the 'include all, for all' distribution is much much greater then the returns will be ... the more you add in, the more you have to co-ordinate releases with the external projects, and pull/push old/new stuff in as it becomes 'stale', etc ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Marc G. Fournier wrote: > But, that isn't our role ... that should be the role of whomever takes > on the role of 'maintainer' for such a monolithic distribution ... its > no more our role to decide that pl/Java is better or worse then pl/J ... > our role is to provide that core for everyone else to build around ... > > People like CommandPrompt, Bizgres, EnterpriseDB, Pervasive ... they > have the funding to *create* and maintain that, to make sure all the > parts they distribute are working properly ... > > The resources are there, if someone (you?) wants to do this as a FOSS > project, but I fear that amount of work (both time and energy) required > to make the 'include all, for all' distribution is much much greater > then the returns will be ... the more you add in, the more you have to > co-ordinate releases with the external projects, and pull/push old/new > stuff in as it becomes 'stale', etc ... Yeah, but if PostgreSQL decides to endorse one monolithic distro in the way I described it could give that project hopefully the necessary lift. And the ultimate goal is obviously that some of those newbies coming by way of the monolithic distro turn into people that bring ressources to the PostgreSQL platform/ecosystem. regards, Lukas
Marc G. Fournier wrote: > > But, that isn't our role ... that should be the role of whomever takes > on the role of 'maintainer' for such a monolithic distribution ... its > no more our role to decide that pl/Java is better or worse then pl/J > ... our role is to provide that core for everyone else to build around > ... > Well, there is money around to sponsor development, and unless that is going to be restricted to core only projects, just giving some sponsorship involves making a choice. Comparisons have been made with perl and CPAN, but modules are adopted into the perl core distribution from time to time. Frankly, people want advice about what is good from people who know. Just saying "Oh, you're all too cute! I can't possibly decide!" might help to keep a fragile peace, but I doubt it does anyone much good in the long run. I'd rather trust the core developers than someone else with possibly more of an axe to grind. cheers andrew
On Thu, 13 Jul 2006, Lukas Kahwe Smith wrote: > Marc G. Fournier wrote: > >> But, that isn't our role ... that should be the role of whomever takes on >> the role of 'maintainer' for such a monolithic distribution ... its no more >> our role to decide that pl/Java is better or worse then pl/J ... our role >> is to provide that core for everyone else to build around ... >> >> People like CommandPrompt, Bizgres, EnterpriseDB, Pervasive ... they have >> the funding to *create* and maintain that, to make sure all the parts they >> distribute are working properly ... >> >> The resources are there, if someone (you?) wants to do this as a FOSS >> project, but I fear that amount of work (both time and energy) required to >> make the 'include all, for all' distribution is much much greater then the >> returns will be ... the more you add in, the more you have to co-ordinate >> releases with the external projects, and pull/push old/new stuff in as it >> becomes 'stale', etc ... > > Yeah, but if PostgreSQL decides to endorse one monolithic distro in the way I > described it could give that project hopefully the necessary lift. And the > ultimate goal is obviously that some of those newbies coming by way of the > monolithic distro turn into people that bring ressources to the PostgreSQL > platform/ecosystem. Should Linus endorse (or does he?) one distro of Linux, or should they not live on their own merits? > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Marc G. Fournier wrote: >> Yeah, but if PostgreSQL decides to endorse one monolithic distro in >> the way I described it could give that project hopefully the necessary >> lift. And the ultimate goal is obviously that some of those newbies >> coming by way of the monolithic distro turn into people that bring >> ressources to the PostgreSQL platform/ecosystem. > > Should Linus endorse (or does he?) one distro of Linux, or should they > not live on their own merits? Well right now PostgreSQL endorses the core distro. I guess similar to the Linux Kernel by Linus. However the difference is that Linux has a huge market share, whereas PostgreSQL is continuously complaing that MySQL is inferior yet way more popular. Maybe MySQL's popularity is not even PostgreSQL's goal, but I am sure a bit more would be welcome. So yes I think right now it would make sense to endorse a monolithic distribution. regards, Lukas
>> Yeah, but if PostgreSQL decides to endorse one monolithic distro in >> the way I described it could give that project hopefully the necessary >> lift. And the ultimate goal is obviously that some of those newbies >> coming by way of the monolithic distro turn into people that bring >> ressources to the PostgreSQL platform/ecosystem. > > Should Linus endorse (or does he?) one distro of Linux, or should they > not live on their own merits? No he does not. I believe leaving the "expert" opinions to the "experts" is a good argument. I also believe that anyone on this list has a right to express their opinion and make it known. However, as a group of which I am a part of, I do not believe we (PostgreSQL.Org) should be endorsing anything but the core project. I for example, will endorse PL/Java. Not because of anything to do with Dave but because of the research I have done to date, PL/Java is more mature. I also currently endorse Slony-I for 8.1 installations but that is only because we don't have a 8.1 release yet (4 weeks W00t!). I on the other hand, do not endorse Perl or anything to do with Perl :) Sincerely, Joshua D. Drake > >> > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email . scrappy@hub.org MSN . scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Thu, 13 Jul 2006, Tom Lane wrote: > The people who think PL/Java is an essential checklist item undoubtedly > also think JDBC is an essential checklist item, but I'm not seeing any > groundswell of support for putting JDBC back into core. Instead we > expect packagers (like the RPM set) to make JDBC available alongside the > core postgres packages. That's how PL/Java ought to be handled, too, > IMHO. The fact that the JDBC driver requires no compilation for anyone on any platform is one reason for that. Anyone can visit the website and be working within minutes with no understanding of the build environment or installation. You drop the provided JAR file in your classpath and you are done. The same cannot be said for pl/java. Yes, it would be good if there were packages for it, but it's very unlikely that pl/java will be able to maintain up to date binary packages for every platform. Another benefit the JDBC project enjoys is a website (jdbc.postgresql.org) and mailing list (pgsql-jdbc@postgresql.org) that are sponsored directly by the project instead of off on a more obscure site (gborg/pgfoundry). Having the archives with the core projects certainly makes them easier to find. Kris Jurka
On Thu, 13 Jul 2006 16:15:04 -0500 (EST) Kris Jurka <books@ejurka.com> wrote: > The fact that the JDBC driver requires no compilation for anyone on any > platform is one reason for that. Anyone can visit the website and be > working within minutes with no understanding of the build environment or > installation. You drop the provided JAR file in your classpath and you > are done. The same cannot be said for pl/java. Yes, it would be good if > there were packages for it, but it's very unlikely that pl/java will be > able to maintain up to date binary packages for every platform. Wouldn't that be the job of the platform providers? Certainly I would expect NetBSD to make it available as a package, both source and binary, on every platform they support as they do for the thousands of other packages they deal with. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
Joshua D. Drake wrote: >> >> JDBC is different, in that it doesn't require the PostgreSQL core to >> build. It's 100% native Java, and as such, I see benefit to it being >> distributed separately. > > PLJava does not need PostgreSQL core to build either. It needs: > > pgxs + Postgresql libs + PostgreSQL headers > > In essence the PostgreSQL SDK. > > If I read what Thomas wrote (late) last night correctly. > You did. Regards, Thomas Hallgren
Jonah H. Harris wrote: > >> But, I can't find anything there to download ... just a pointer to a >> Wiki, >> which, I'm sorry, would definitely not be my first thought to go look at >> for a downloads ... > > Hmm, yes... just saw that and it is a bit odd. Thomas, I like the > layout of the Wiki... but could we move the project files to pgfoundry > for hosting and set the project's home page as the wiki? > Yes, that sounds reasonable. I'll look into that. What I really would like is to move the whole project (aside from the Wiki) from gborg to pgfoundry. Kind regards, Thomas Hallgren
Marc G. Fournier wrote: > > So, let's try ftp ... > > ftp.postgresql.org:/pub/projects/gborg/pljava/stable: > > Nothing there newer then November 2005: > > ftp> ls -lt > 227 Entering Passive Mode (66,98,251,159,248,251) > 150 Opening ASCII mode data connection for /bin/ls. > total 23026 > -rw-r--r-- 1 80 1009 206134 Nov 20 2005 pljava-src-1.2.0.tar.gz > -rw-r--r-- 1 80 1009 522895 Nov 20 2005 > pljava-i686-pc-mingw32-pg8.1-1.2.0.tar.gz > -rw-r--r-- 1 80 1009 522955 Nov 20 2005 > pljava-i686-pc-mingw32-pg8.0-1.2.0.tar.gz > -rw-r--r-- 1 80 1009 421717 Nov 20 2005 > pljava-i686-pc-linux-gnu-pg8.1-1.2.0.tar.gz > -rw-r--r-- 1 80 1009 421999 Nov 20 2005 > pljava-i686-pc-linux-gnu-pg8.0-1.2.0.tar.gz > > so, if there is a newer version (I actually eventually went to the > wiki, so know there is a 1.3.0), its not taking advantage of the > PostgreSQL file distribution network that has been developed over the > years ... > How would I go about taking advantage of that? And who did the 1.2.0 upload? I certainly didn't. Kind Regards, Thomas Hallgren
On Thu, 13 Jul 2006, D'Arcy J.M. Cain wrote: > Wouldn't that be the job of the platform providers? Certainly I would > expect NetBSD to make it available as a package, both source and > binary, on every platform they support as they do for the thousands of > other packages they deal with. > Well NetBSD doesn't offer pl/java now so I'm not sure what point you are trying to make. Sure it would be nice if every OS provided every version of every package, but when they don't what are you going to do about it? Provide a complete package or require manual assembly? Kris Jurka
On Fri, 14 Jul 2006, Thomas Hallgren wrote: > Marc G. Fournier wrote: >> >> So, let's try ftp ... >> >> ftp.postgresql.org:/pub/projects/gborg/pljava/stable: >> >> Nothing there newer then November 2005: >> >> ftp> ls -lt >> 227 Entering Passive Mode (66,98,251,159,248,251) >> 150 Opening ASCII mode data connection for /bin/ls. >> total 23026 >> -rw-r--r-- 1 80 1009 206134 Nov 20 2005 pljava-src-1.2.0.tar.gz >> -rw-r--r-- 1 80 1009 522895 Nov 20 2005 >> pljava-i686-pc-mingw32-pg8.1-1.2.0.tar.gz >> -rw-r--r-- 1 80 1009 522955 Nov 20 2005 >> pljava-i686-pc-mingw32-pg8.0-1.2.0.tar.gz >> -rw-r--r-- 1 80 1009 421717 Nov 20 2005 >> pljava-i686-pc-linux-gnu-pg8.1-1.2.0.tar.gz >> -rw-r--r-- 1 80 1009 421999 Nov 20 2005 >> pljava-i686-pc-linux-gnu-pg8.0-1.2.0.tar.gz >> >> so, if there is a newer version (I actually eventually went to the wiki, so >> know there is a 1.3.0), its not taking advantage of the PostgreSQL file >> distribution network that has been developed over the years ... >> > How would I go about taking advantage of that? And who did the 1.2.0 > upload? I certainly didn't. There is alot more then then just 1.2.0 ... check out the FTP site ... As for taking advantage of that ... upload files to the file section in *either* gborg or pgfoundry, and they get auto-included as part of the ftp network ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Thu, 13 Jul 2006, Bort, Paul wrote: > Does PL/Java really have to be in core to be tested in the build farm? > Could the build farm code be enhanced to test non-core stuff? (I like > the idea of a separate status 'light' for non-core.) Andrew posted about his desires for the future of the Buildfarm, and it included being able to pull in projects from pgFoundry and run tests on them ... > Regarding the packagers who don't include non-core components that their > users might like, would a README.distros help? It could suggest good > things to include, where to find them, and tips for building. This could > also distinguish the mature packages on pgFoundry from the ones that are > not quite ready for prime time: when a package's maintainer(s) think > it's ready for production, they could submit a patch to the > README.distros that adds the package. (I'm not attached to the filename, > it just seemed less confusing than README.packagers.) I don't know how Linux does it for packages, but in FreeBSD, "ports" are created based on what ppl are using, and, generally, are built/submitted by ppl using a particular piece of software ... They aren't necessarily that difficult to create, but it does generally require someone to 'care enough' to MAINTAIN it ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Jonah H. Harris wrote: > Because, the fact is that it's a PITA and many people don't even go > far enough to look. If major components of PostgreSQL were included > in the core, it would make it much easier for people; especially those > familiar with commercial-class database systems. Those familiar with commercial-class database systems rarely compile source code distributions to set up DBMS installations. Those familiar with commercial-class database systems may be happy with Devrim's pgnixinstaller, but that's not what we are discussing here.
On Thu, 13 Jul 2006, Kris Jurka wrote: > > > On Thu, 13 Jul 2006, D'Arcy J.M. Cain wrote: > >> Wouldn't that be the job of the platform providers? Certainly I would >> expect NetBSD to make it available as a package, both source and >> binary, on every platform they support as they do for the thousands of >> other packages they deal with. >> > > Well NetBSD doesn't offer pl/java now so I'm not sure what point you are > trying to make. Sure it would be nice if every OS provided every version of > every package, but when they don't what are you going to do about it? Provide > a complete package or require manual assembly? Well, in the case of FreeBSD, I can easily volunteer that if someone wanted to make a port of pl/java to include, I can commit it for them ... I don't know how NetBSDs system works, but I suspect it is similar ... the only reason 'NetBSD doesn't offer pl/java now' is because nobody a) is using it under NetBSD or b) submitted a port to their system Hey JD, I notice that we don't have a port for plphp either ... if one of your guys wants to create one, I can get it committed ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Marc G. Fournier wrote: >> How would I go about taking advantage of that? And who did the 1.2.0 >> upload? I certainly didn't. > > There is alot more then then just 1.2.0 ... check out the FTP site ... > > As for taking advantage of that ... upload files to the file section > in *either* gborg or pgfoundry, and they get auto-included as part of > the ftp network ... > The PL/Java 1.3.0 release has been on gborg for several weeks but only available through the wiki (the gborg generated 'download' page is messy and I'm not able to remove stuff that shouldn't be there). I guess that's why it was not mirrored. And yes, I agree wholeheartedly, a wiki is not the most intuitive place for downloads. Per Jonahs suggestion I've just uploaded everything to pgfoundry too. Thanks for uploading the 1.3.0 to the ftp. Regards, Thomas Hallgren
On Thu, 13 Jul 2006, Bruce Momjian wrote: > Marc G. Fournier wrote: >> On Thu, 13 Jul 2006, Rod Taylor wrote: >> >>> A slight restructuring of the FTP tree should probably be made. It's >>> currently very easy to find the main pgsql, pgadmin and odbc components. >>> Finding pl/java (what the heck is that gborg or pgfoundry project?) is >>> pretty difficult. >> >> The gborg vs pgfoundry issue is being worked on, albeit slowly ... gborg >> is being 'sucked into' pgfoundry, but with OSCON and the Conference, and >> summer holidays, things have slowed down a bit .... > > How can you slow from zero? ;-) Since discussions and coordination of the migration of gborg to pgfoundry happens on a closed list that I do not believe you are a member of, you are basing this "zero" on the fact that ... the scripts to do the migration haven't been sufficiently tested for us to do it on the live site yet? :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Fri, 14 Jul 2006, Thomas Hallgren wrote: > Marc G. Fournier wrote: >>> How would I go about taking advantage of that? And who did the 1.2.0 >>> upload? I certainly didn't. >> >> There is alot more then then just 1.2.0 ... check out the FTP site ... >> >> As for taking advantage of that ... upload files to the file section in >> *either* gborg or pgfoundry, and they get auto-included as part of the ftp >> network ... >> > The PL/Java 1.3.0 release has been on gborg for several weeks but only > available through the wiki (the gborg generated 'download' page is messy and > I'm not able to remove stuff that shouldn't be there). I'm confused here ... "has been on gborg for several weeks, but only available through the wiki" ... On: http://gborg.postgresql.org/project/pljava/projdisplay.php ... I can't find any way of downloading 1.3.0 (or, older releases even) ... have you been uploading, but nobody activated teh Files section to download? :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Marc G. Fournier wrote: > > I'm confused here ... "has been on gborg for several weeks, but only > available through the wiki" ... > > On: http://gborg.postgresql.org/project/pljava/projdisplay.php ... I > can't find any way of downloading 1.3.0 (or, older releases even) ... > have you been uploading, but nobody activated teh Files section to > download? :( > Yes, I've been uploading to gborg and the links provided on the wiki appoints those files. I don't *want* to activate the downloads section since it exposes a page with a lot of files that I doesn't belong there. Unfortunately, there's no way to remove them. The Files section on pgfoundry looks a lot better :-) Regards, Thomas Hallgren
Jonah H. Harris wrote: > True. Then maybe we should just all work together to make a > distribution suggestion to packagers of the major components and their > versions. That way the packagers at least have a good idea of what we > believe is "good-to-go" with X version of PostgreSQL. Which operating system have you actually looked at that does not provide what you need?
On Thu, 13 Jul 2006 19:54:19 -0300 (ADT) "Marc G. Fournier" <scrappy@postgresql.org> wrote: > > Well NetBSD doesn't offer pl/java now so I'm not sure what point you are > > trying to make. Sure it would be nice if every OS provided every version of > > every package, but when they don't what are you going to do about it? Provide > > a complete package or require manual assembly? > > Well, in the case of FreeBSD, I can easily volunteer that if someone > wanted to make a port of pl/java to include, I can commit it for them ... > I don't know how NetBSDs system works, but I suspect it is similar ... the > only reason 'NetBSD doesn't offer pl/java now' is because nobody a) is > using it under NetBSD or b) submitted a port to their system And I can commit it to NetBSD if someone sends it to me. I don't use PL/Java myself so I can't test it but I can make sure that it compiles and put it into our pkgsrc tree. We have a build farm for packages so I can confirm it for all the platforms we run on. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
Joshua D. Drake wrote: > Were trying man :) I have people building for most major distributions > at this point. We should have FreeBSD soon, as well as MacOSX. How is this different (or better) than what is already in FreeBSD ports?
Marc G. Fournier wrote: > ... the only reason 'NetBSD doesn't offer pl/java now' is because nobody > a) is using it under NetBSD or b) submitted a port to their system > Should be fairly straight forward if the PostgreSQL SDK and gcj 4.0 or later is installed. Download the PL/Java source tarball, make sure pg_ctl is in your path and type 'make USE_GCJ=1 release' Alternatively, set JAVA_HOME to appoint some other JRE and just type 'make release' Regards, Thomas Hallgren
Lukas Kahwe Smith wrote: > whereas PostgreSQL is continuously complaing that > MySQL is inferior yet way more popular. Maybe MySQL's popularity is not > even PostgreSQL's goal, but I am sure a bit more would be welcome. Does MySQL have a monolithic distribution?
On Thu, 13 Jul 2006, D'Arcy J.M. Cain wrote: > On Thu, 13 Jul 2006 19:54:19 -0300 (ADT) > "Marc G. Fournier" <scrappy@postgresql.org> wrote: >>> Well NetBSD doesn't offer pl/java now so I'm not sure what point you are >>> trying to make. Sure it would be nice if every OS provided every version of >>> every package, but when they don't what are you going to do about it? Provide >>> a complete package or require manual assembly? >> >> Well, in the case of FreeBSD, I can easily volunteer that if someone >> wanted to make a port of pl/java to include, I can commit it for them ... >> I don't know how NetBSDs system works, but I suspect it is similar ... the >> only reason 'NetBSD doesn't offer pl/java now' is because nobody a) is >> using it under NetBSD or b) submitted a port to their system > > And I can commit it to NetBSD if someone sends it to me. I don't use > PL/Java myself so I can't test it but I can make sure that it > compiles and put it into our pkgsrc tree. We have a build farm for > packages so I can confirm it for all the platforms we run on. Agreed, FreeBSD has similar ... as soon as its in our ports system, it will be auto-built/packaged for each platform we support, which includes, but is not limited to, i386, AMD64 and Solaris ... But Thomas, that means finding someone willing to do the work to build the port ... :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Kris Jurka wrote: > > > On Thu, 13 Jul 2006, Tom Lane wrote: > >> The people who think PL/Java is an essential checklist item >> undoubtedly also think JDBC is an essential checklist item, but I'm >> not seeing any groundswell of support for putting JDBC back into >> core. Instead we expect packagers (like the RPM set) to make JDBC >> available alongside the core postgres packages. That's how PL/Java >> ought to be handled, too, IMHO. > > The fact that the JDBC driver requires no compilation for anyone on any > platform is one reason for that. Anyone can visit the website and be > working within minutes with no understanding of the build environment or > installation. You drop the provided JAR file in your classpath and you > are done. The same cannot be said for pl/java. Yes, it would be good if > there were packages for it, but it's very unlikely that pl/java will be > able to maintain up to date binary packages for every platform. The problem I pointed in my previous post, is internal changes impact to several PostgreSQL extensions and components. They should be developed, tested and shipped more tightly. The JDBC driver does connect to the backend via well-defined protocol, so separated development is not a problem. The protocol means a contract between frontend and backend. However, several extensions, such as pl/java, strongly depend on the backend internal functions and arguments. If they are suddenly changed, the extension XX couldn't be compiled anymore, and the users will waste their time. No one gets win if such impedance mismatch exists. -- NAGAYASU Satoshi <nagayasus@nttdata.co.jp> Phone: +81-3-3523-8122
On Fri, 14 Jul 2006, Thomas Hallgren wrote: > Marc G. Fournier wrote: >> >> I'm confused here ... "has been on gborg for several weeks, but only >> available through the wiki" ... >> >> On: http://gborg.postgresql.org/project/pljava/projdisplay.php ... I can't >> find any way of downloading 1.3.0 (or, older releases even) ... have you >> been uploading, but nobody activated teh Files section to download? :( >> > Yes, I've been uploading to gborg and the links provided on the wiki appoints > those files. I don't *want* to activate the downloads section since it > exposes a page with a lot of files that I doesn't belong there. Ah, okay, that I didn't know ... thank you for clarifying that :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
> Hey JD, I notice that we don't have a port for plphp either ... if one > of your guys wants to create one, I can get it committed ... DarcyB is supposed to be handling that :) Joshua D. Drake > > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email . scrappy@hub.org MSN . scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Thu, 13 Jul 2006, Chris Browne wrote: > kleptog@svana.org (Martijn van Oosterhout) writes: >> On Thu, Jul 13, 2006 at 01:26:30PM -0400, Tom Lane wrote: >>> The right way to proceed is what was mentioned in another message: >>> work harder at educating packagers about which non-core projects >>> are worth including in their packages. I have to confess >>> contributing to the problem, as I'm not currently including >>> eg. Slony in the Red Hat RPMs. I certainly should be --- but >>> "fixing" that by pushing Slony into the core PG distro is not a >>> solution. >> >> Indeed. Distributors are not going to go through pgfoundary and >> package everything, there's just no point. I think it would be very >> useful to dedicate a portion of the website to add-ons that are >> considered worthwhile. > > If there were enough chunks of it that were buildable using pgxs or > similar such that they could pretty readily script up... > > for project in `echo $LIST`; do > cd $DOWNLOADS > wget http://downloads.pgfoundry.org/${project}/${project}-latest.tar.bz2 > cd $BUILDHOME > mkdir $${project} > cd $${project} > tar xfvj $DOWNLOADS/${project}-latest.tar.bz2 > cd * > ./configure --pgxs-options --path=/usr --rpm-deteriorata > make install > run-rpm-file-collector $${project} > done > > The folks running Perl and Python repositories have gotten the > "toolage" together so that you can pull CPAN packages and very nearly > turn them into RPM packages. > > If we have an interestingly large set of packages at pgFoundry that > are "that RPMable," then they *will* come. Well, the other thing to point out is that there is nothing stop'ng ppl from building and uploading their own RPM binaries to pgfoundry ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Marc G. Fournier wrote: > But Thomas, that means finding someone willing to do the work to build > the port ... :) > PL/java should be very easy to port. In fact, I'm not sure any specific porting is needed. There might be some minor makefile quirk (that is what has bitten me on other platforms). I don't have access to a FreeBSD machine so I can't try it. Regards, Thomas Hallgren
I understand that we have an issue, with Slony-I, concerning the new
"standards_conforming_strings" option in 8.2.
Slony-I uses the "legacy" quoting conventions, which, such as it is,
is fine.
If a particular server is set to standards_conforming_strings=on, this
will presumably lead to certain bits of "breakage."
Is that a GUC variable that may be overridden in the fashion of
datestyles? (e.g. - inside Slony-I, we set DateStyle = USE_ISO_DATES
in those places where it's needful)
Could that variable be escape_backslash? (described in c.h...)
/** Support macros for escaping strings. escape_backslash should be TRUE * if generating a non-standard-conforming
string. Prefixing a string * with ESCAPE_STRING_SYNTAX guarantees it is non-standard-conforming. * Beware of
multipleevaluation of the "ch" argument! */
e.g. - we might force non-standard-conforming via a code segment like...
{ int Oldescape_backslash; Oldescape_backslash = escape_backslash; escape_backslash = TRUE; do some
stuff...
escape_backslash = Oldescape_backslash;
}
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www.ntlug.org/~cbbrowne/x.html
"Moebius strippers only show you their back side." -- Unknown
Peter Eisentraut wrote: > Joshua D. Drake wrote: >> Were trying man :) I have people building for most major distributions >> at this point. We should have FreeBSD soon, as well as MacOSX. > > How is this different (or better) than what is already in FreeBSD ports? There is no functional difference. It is a business difference. It is supported. It is also the idea that we will provide newer postgresql releases for all the support platforms. Like how we provide RPMS even for older version of Fedora. Most people who run FreeBSD have no need for Mammoth, until possibly they want to upgrade via ports to a new version of PostgreSQL but they don't want to upgrade FreeBSD. Sincerely, Joshua D. Drake > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Thursday 13 July 2006 15:39, Joshua D. Drake wrote:
> Marc G. Fournier wrote:
> > On Thu, 13 Jul 2006, Joshua D. Drake wrote:
> >>> Aside from obviously the big issue of who maintains all the pgfoundry
> >>> stuff, I also think that the PostgreSQL family would benefit from a
> >>> distribution that is more "and the kitchen sink" style. I do not know
> >>> exactly if Bizgres could be considered just that? Or maybe it could get
> >>> promoted to be that?
> >>
> >> Lukas, that is what www.mammothpostgresql.org is :)
> >
> > Then *it* needs to be promoted more, since this is actually the first
> > I'd heard of it :(
>
> Were trying man :) I have people building for most major distributions
> at this point. We should have FreeBSD soon, as well as MacOSX.
>
I believe it was Lukas who mentioned elsewhere, this is not a vendor nuetral
project. I actually am already working on a adding a list of os/package
options to the download page based on other feedback, are people comfortable
allowing mammothpostgresql to go on that list? (I wouldn't be mainly because
I don't see a clear distinction between it and things like mammoth
replicator)
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
Hi, On Thu, 2006-07-13 at 15:33 -0400, Chris Browne wrote: > If we have an interestingly large set of packages at pgFoundry that > are "that RPMable," then they *will* come. Personally I am interested in building all RPMable PostgreSQL related projects. Currently I do packaging for PostgreSQL, pgadmin3, Slony-I, PostGIS, libpqxx, dbi-link, plphp, postgresql_autodoc, psycopg. I know that some projects at pgfoundry build their own RPM packages. If any of the maintainers need help in RPM packaging, please let me know. I'm pretty sure that our RPM packagers at pgsqlrpms project will help us, too. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
> > I believe it was Lukas who mentioned elsewhere, this is not a vendor nuetral > project. I actually am already working on a adding a list of os/package > options to the download page based on other feedback, are people comfortable > allowing mammothpostgresql to go on that list? (I wouldn't be mainly because > I don't see a clear distinction between it and things like mammoth > replicator) The distinction is that mammoth postgresql doesn't have replication :). It is fairly clear on the website. All the links on the CMD website take you directly to www.mammothpostgresql.org which very clearly states: Mammoth PostgreSQL is a business and developer complete PostgreSQL Distribution. Based on PostgreSQL 8.1.4, Mammoth PostgreSQL is designed to provide all the software you need to use PostgreSQL in your environment. The distribution is 100% F/OSS sofware with the exclusion of Mammoth Replicator which can be purchased separately. -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Thu, 13 Jul 2006, Joshua D. Drake wrote: > Most people who run FreeBSD have no need for Mammoth, until possibly > they want to upgrade via ports to a new version of PostgreSQL but they > don't want to upgrade FreeBSD. 'k, up to now, you had me ... but what does upgrading to a new version of PostgreSQL have to do with upgrading FreeBSD? They are totally different sub-systems ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Thu, 13 Jul 2006, Robert Treat wrote: > On Thursday 13 July 2006 15:39, Joshua D. Drake wrote: >> Marc G. Fournier wrote: >>> On Thu, 13 Jul 2006, Joshua D. Drake wrote: >>>>> Aside from obviously the big issue of who maintains all the pgfoundry >>>>> stuff, I also think that the PostgreSQL family would benefit from a >>>>> distribution that is more "and the kitchen sink" style. I do not know >>>>> exactly if Bizgres could be considered just that? Or maybe it could get >>>>> promoted to be that? >>>> >>>> Lukas, that is what www.mammothpostgresql.org is :) >>> >>> Then *it* needs to be promoted more, since this is actually the first >>> I'd heard of it :( >> >> Were trying man :) I have people building for most major distributions >> at this point. We should have FreeBSD soon, as well as MacOSX. >> > > I believe it was Lukas who mentioned elsewhere, this is not a vendor nuetral > project. I actually am already working on a adding a list of os/package > options to the download page based on other feedback, are people comfortable > allowing mammothpostgresql to go on that list? (I wouldn't be mainly because > I don't see a clear distinction between it and things like mammoth > replicator) I have no problems with it ... there is no license or cost to use, and, I'm guessing from what Joshua has said, the source code come with it ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Fri, 14 Jul 2006, Thomas Hallgren wrote: > Marc G. Fournier wrote: >> But Thomas, that means finding someone willing to do the work to build the >> port ... :) >> > PL/java should be very easy to port. In fact, I'm not sure any specific > porting is needed. There might be some minor makefile quirk (that is what has > bitten me on other platforms). I don't have access to a FreeBSD machine so I > can't try it. Sorry, didn't mean to confuse here ... not "port it to FreeBSD", but "build a FreeBSD port" for the ports system ... Here is the docuementatin for it: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html As well as OpenBSD: http://www.openbsd.org/porting.html And, for NetBSD, all I'm finding is the following, but D'Arcy would be able to point further ... http://www.netbsd.org/Documentation/software/packages.html ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Fri, 14 Jul 2006, Peter Eisentraut wrote: > Lukas Kahwe Smith wrote: >> whereas PostgreSQL is continuously complaing that >> MySQL is inferior yet way more popular. Maybe MySQL's popularity is not >> even PostgreSQL's goal, but I am sure a bit more would be welcome. > > Does MySQL have a monolithic distribution? Not any time I've ever had to install it ... no odbc, no jdbc, no nothing ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Marc G. Fournier wrote: > On Thu, 13 Jul 2006, Joshua D. Drake wrote: > >> Most people who run FreeBSD have no need for Mammoth, until possibly >> they want to upgrade via ports to a new version of PostgreSQL but they >> don't want to upgrade FreeBSD. > > 'k, up to now, you had me ... but what does upgrading to a new version > of PostgreSQL have to do with upgrading FreeBSD? They are totally > different sub-systems ... I am not exactly sure how it works in FreeBSD but I can speak from Fedora and Ubuntu. For example there is NOT an PostgreSQL 8.1 for Ubuntu Breezy. We want to continue to provide for older distributions (without breaking package compatibility). Sincerely, Joshua D. Drake > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email . scrappy@hub.org MSN . scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
>> I believe it was Lukas who mentioned elsewhere, this is not a vendor >> nuetral >> project. I actually am already working on a adding a list of os/package >> options to the download page based on other feedback, are people >> comfortable >> allowing mammothpostgresql to go on that list? (I wouldn't be mainly >> because >> I don't see a clear distinction between it and things like mammoth >> replicator) > > I have no problems with it ... there is no license or cost to use, and, > I'm guessing from what Joshua has said, the source code come with it ... Yep, direct access :) > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email . scrappy@hub.org MSN . scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Thu, 13 Jul 2006, Joshua D. Drake wrote: > Marc G. Fournier wrote: >> On Thu, 13 Jul 2006, Joshua D. Drake wrote: >> >>> Most people who run FreeBSD have no need for Mammoth, until possibly they >>> want to upgrade via ports to a new version of PostgreSQL but they don't >>> want to upgrade FreeBSD. >> >> 'k, up to now, you had me ... but what does upgrading to a new version of >> PostgreSQL have to do with upgrading FreeBSD? They are totally different >> sub-systems ... > > I am not exactly sure how it works in FreeBSD but I can speak from Fedora and > Ubuntu. Ah, okay ... FreeBSD has a ports system that can be updated seperate from teh operating system using cvsup ... in my case, I run cvsup nightly, just to make sure my ports tree is up to date ... So, if I'm running 8.1.3 right now on my desktop, and 8.1.4 is now in the new ports tree, the next time I run an update of my ports, postgresql will get upgraded to 8.1.4 ... note that most ppl upgrade ports interactively, so I'm not advocating blindly upgrading and overwriting your old version :) I have a couple of FreeBSD 4.x servers that are running 8.1.4 PostgreSQL from ports ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Fri, 14 Jul 2006, Satoshi Nagayasu wrote: > However, several extensions, such as pl/java, strongly depend on the > backend internal functions and arguments. If they are suddenly changed, > the extension XX couldn't be compiled anymore, and the users will waste > their time. There are several flaws to this ... First and foremost, it assumes that those 'users' aren't going to make sure that the version of pl/java they are trying to install has the version of postgresql they are running listed as being compatible ... Second, its assuming that Thomas, or any other pl/java developer, *isn't* going to watching for any changes to the API fairly closely, considering they know it does happen, and, therefore, won't make a change to their development code to accommodate that when the time comes ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Thu, 13 Jul 2006, Jonah H. Harris wrote: > On 7/13/06, Marc G. Fournier <scrappy@postgresql.org> wrote: >> 'k, but, again, this comes to someone (you?) stepping forward and >> dedicating the time/energy to developing a 'mega distribution', and being >> willing to provide support for it > > True. Then maybe we should just all work together to make a > distribution suggestion to packagers of the major components and their > versions. That way the packagers at least have a good idea of what we > believe is "good-to-go" with X version of PostgreSQL. This works,to an extent ... but what packagers are you referring to? I know with FreeBSD, there is no "one packager for all things postgresql ... > Not to be too "business" about it, but a PostgreSQL community > distribution should IMHO, be vendor neutral. If the installer were > vendor-branding-free, I'd be game. The big problem is that there is no 'single package format' out there, so any installer would be fairly difficult from that perspective, i think ... you'd have to have a 'pgrpm-installer' vs 'pgdeb-installer' vs 'pgpkg-installer' vs ... ? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Marc G. Fournier wrote: > > Second, its assuming that Thomas, or any other pl/java developer, > *isn't* going to watching for any changes to the API fairly closely, > considering they know it does happen, and, therefore, won't make a > change to their development code to accommodate that when the time > comes ... > As we have explained before, there really isn't an API in any meaningful sense. Thomas will undoubtedly be vigilant, but the real danger is that something non-obvious will change and break stuff. cheers andrew
On Thu, 13 Jul 2006, Andrew Dunstan wrote: > Tom Lane wrote: > >> The right way to proceed is what was mentioned in another message: work >> harder at educating packagers about which non-core projects are worth >> including in their packages. I have to confess contributing to the >> problem, as I'm not currently including eg. Slony in the Red Hat RPMs. >> I certainly should be --- but "fixing" that by pushing Slony into the >> core PG distro is not a solution. >> >> > > Well, there are other good reasons not to in the slony case. > > But anyway, I was wondering if we could make life easier by providing a > script which would fetch some set of addon features, and make building the > whole lot together easy. > > No doubt some people will not want to make choices, but I think we need to, > to some extent. I broadly agree with what Martijn has just said, although I > doubt that pgFoundry's Top Downloads section is much of a guide. If we > recommend something we need to be prepared to exerciase some jusgement and > have the courage of our convictions. > > Personally, I would start with: > > pl/java > pl/ruby > pl/php > jdbc driver > odbc driver > npgsql > python stuff (not sure which, as I don't use it) >> > The perl and php clients, and libpqxx would also be possibilities. Just a thought, but if one of the big beefs is ppl not finding out about things, why not just add a simple README.addons to the distribution, and have it so that when a 'make install' is finished, the last thing that happens is this get 'less'd to their screen? The thing is, this whole discussion is moot *except* as far as packagers are concerned, or the ones that download from ftp.postgresql.org and build from source ... a packager is going to split all those individual 'extras' off into seperate packages, or, I imagine, in alot of cases, not do *anything* with them as its not within their realm of interest ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Thu, 13 Jul 2006, Andrew Dunstan wrote: > Marc G. Fournier wrote: >> >> Second, its assuming that Thomas, or any other pl/java developer, *isn't* >> going to watching for any changes to the API fairly closely, considering >> they know it does happen, and, therefore, won't make a change to their >> development code to accommodate that when the time comes ... >> > As we have explained before, there really isn't an API in any meaningful > sense. Thomas will undoubtedly be vigilant, but the real danger is that > something non-obvious will change and break stuff. But, as Tom has already explained, *he's* not going to make changes pl/java if its committed ... how many will even have java (or gcj) to even test it to see if its broken? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Thu, 13 Jul 2006, Jonah H. Harris wrote: > On 7/13/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> This is really the whole issue right here: you want a monolithic "core" >> distribution. I cannot begin to list the number of things wrong with >> that approach, but suffice it to say that that's not the way PostgreSQL >> is moving. > > I'm not going to argue at all and will gladly second Josh's statement. > If the core doesn't want to include it, commercial companies > (EnterpriseDB, Command Prompt, ...) and consultants will continue to > do it for us. Isn't that what is called creating a 'Value Added Product'? Our *product* is PostgreSQL RDBMS ... not "PostgreSQL RDBMS and everything that you can use to interface with it" ... > I don't think we should include everything, and I belive that "collapse" > is debatable. The important part is how the distro itself is managed. > One can easily create a "core" distribution which includes PL/Java, > ODBC, JDBC, etc. All of them don't have to reside in the same CVS tree, > but they can be built and released together. I know because I've done > it... and it's not that difficult. The hard part is actually deciding > what to include and what not to. 'k, now, why don't you take that script you would have developed to pull all those parts together and create a pgFoundry project for it, so that the work you did doesn't get lost, and/or others can build on it? > Like I said, this discussion always seems to come up and we always go > back to saying "leave it to pgfoundry", "we'll promote pgfoundry", > "pgfoundry is the best place for it". Yet, I haven't really seen any > action to make pgfoundry any better or more well-known. Do you have any suggestions to this end? Considering that my first search on pl java produced both gborg and pgfoundry before the actual development site/wiki for pl/java, from a search engine, they are both well known ... > OK, but who is going to do this? It certainly doesn't sound like any of > us want to spend the time educating packagers as we're either working on > our own things or for companies that already do package PostgreSQL. The maintainers of the non-core projects should be doing this ... it should be our job to promote either pl/Java *or* pl/J as being one better then the other ... I know with the *BSD camps, *anyone* can build a package ... I'm guessing that it isn't that hard on the Linux side either ... so why is there a set group of "packagers" that even have to be addressed/educated? I know within the FreeBSD "porters" community, there are *at least* 6 different ppl that deal with packages that revolve around PostgreSQL ... does, as an example, pl/Java not have *any* FreeBSD ppl? NetBSD? Someone that has one of them that can read a set of instructions to create the package and submit it the respective project for inclusion? In the case of both FreeBSD and NetBSD, both D'Arcy and I have offered to make sure that they get in, we're just not in a position to actually build the port/package itself ... The thing is, IMHO ... if you have 100 ppl willing to build an RPM package, but none of them have any interest in java, you aren't going to convince any of them to build the package ... you need to find someone *within* the non-core project with a desire to build it, and take responsibility for it. For *core*, Devrim step'd up long ago for doing RPMs ... but, and I may be wrong, but I doubt he'd going through extra effort to build a pljava RPM just because it was part of core, especially if he a) knows nothing about java and b) doesn't even have java installed ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Marc G. Fournier wrote: > On Thu, 13 Jul 2006, Andrew Dunstan wrote: > >> Marc G. Fournier wrote: >>> >>> Second, its assuming that Thomas, or any other pl/java developer, >>> *isn't* going to watching for any changes to the API fairly closely, >>> considering they know it does happen, and, therefore, won't make a >>> change to their development code to accommodate that when the time >>> comes ... >>> >> As we have explained before, there really isn't an API in any >> meaningful sense. Thomas will undoubtedly be vigilant, but the real >> danger is that something non-obvious will change and break stuff. > > But, as Tom has already explained, *he's* not going to make changes > pl/java if its committed ... how many will even have java (or gcj) to > even test it to see if its broken? > Quite so. That's why buildfarm for pl/java will be important when I can get it done. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Quite so. That's why buildfarm for pl/java will be important when I can
> get it done.
+1 --- the important point about an arrangement like that is that it'll
be clear from the buildfarm results that pljava is broken, and not the
whole system. (Contrast the current all-red status board, which I feel
safe in blaming on Bruce ... off to take a look ...)
regards, tom lane
I'm disappointed. Can you point out past discussion for this? -- Tatsuo Ishii SRA OSS, Inc. Japan > Mario Weilguni wrote: > > Will this patch make it into 8.2? > > http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php > > > > It's a really nice feature, would be extremly useful with tools like pgpool. > > No, it will not because RESET CONNECTION can mess up interface code that > doesn't want the connection reset. We are not sure how to handle that. > > --------------------------------------------------------------------------- > > > > > > Am Freitag, 7. Juli 2006 19:13 schrieb Bruce Momjian: > > > There are roughly three weeks left until the feature freeze on August 1. > > > If people are working on items, they should be announced before August > > > 1, and the patches submitted by August 1. If the patch is large, it > > > should be discussed now and an intermediate patch posted to the lists > > > soon. > > > > > > FYI, we don't have many major features ready for 8.2. > > > > > > -- > > > Bruce Momjian bruce@momjian.us > > > EnterpriseDB http://www.enterprisedb.com > > > > > > + If your life is a hard drive, Christ can be your backup. + > > > > > > ---------------------------(end of broadcast)--------------------------- > > > TIP 5: don't forget to increase your free space map settings > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 1: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to majordomo@postgresql.org so that your > > message can get through to the mailing list cleanly > > -- > Bruce Momjian bruce@momjian.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match >
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > > Quite so. That's why buildfarm for pl/java will be important when I can > > get it done. > > +1 --- the important point about an arrangement like that is that it'll > be clear from the buildfarm results that pljava is broken, and not the > whole system. (Contrast the current all-red status board, which I feel > safe in blaming on Bruce ... off to take a look ...) I think the pending patch adding limit.h and stuff will fix it. Will apply. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Peter Eisentraut wrote: > Lukas Kahwe Smith wrote: >> whereas PostgreSQL is continuously complaing that >> MySQL is inferior yet way more popular. Maybe MySQL's popularity is not >> even PostgreSQL's goal, but I am sure a bit more would be welcome. > > Does MySQL have a monolithic distribution? Well obviously MySQL is missing alot of functionality that you will not get in any version of MySQL though. However it comes with replication, fulltext indexes out of the box. They currently only have a single stored procedure language (partial SQL:2003 implementation). regards, Lukas
Lukas Smith wrote: > Peter Eisentraut wrote: >> Lukas Kahwe Smith wrote: >>> whereas PostgreSQL is continuously complaing that >>> MySQL is inferior yet way more popular. Maybe MySQL's popularity is not >>> even PostgreSQL's goal, but I am sure a bit more would be welcome. >> >> Does MySQL have a monolithic distribution? > > Well obviously MySQL is missing alot of functionality that you will not > get in any version of MySQL though. > > However it comes with replication, fulltext indexes out of the box. They > currently only have a single stored procedure language (partial SQL:2003 > implementation). Oh and they also ship a federated (AFAIK their dblink answer) along with several other storage engines for various specific tasks. regards, Lukas
Joshua D. Drake wrote: > For example there is NOT an PostgreSQL 8.1 for Ubuntu Breezy. http://packages.ubuntu.com/breezy-backports/misc/ -- Peter Eisentraut http://developer.postgresql.org/~petere/
Ühel kenal päeval, K, 2006-07-12 kell 17:48, kirjutas Thomas Hallgren: > Andrew Dunstan wrote: > > There is in effect no API at all, other than what is available to all > > backend modules. If someone wants to create an API which will be both > > sufficiently stable and sufficiently complete to meet the needs of the > > various PLs (especially, as Hannu rightly observes, any new PLs that > > come along) then we can revisit this question. Until then I suggest > > that it is at best premature. I am not even sure such a thing is > > actually possible. > > > I concur with this. The needs for a module like PL/Java is very different then the needs of > PL/Perl so let's get some more PL's in before we do a refactoring effort to create common > API's. Personally, I'm not sure what would be included. The call handler API's together with > the SPI API's are in essence what you need. The rest is fairly specialized anyway. http://pgfoundry.org/projects/python seems to do something similar to what you describe for PL/Java. For example it is using postgreSQLs native types and operators for calculations instead of converting types to pl's native types. and it also has lots of code lines ;) -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com
Lukas Smith wrote: > Lukas Smith wrote: >> Peter Eisentraut wrote: >>> Lukas Kahwe Smith wrote: >>>> whereas PostgreSQL is continuously complaing that >>>> MySQL is inferior yet way more popular. Maybe MySQL's popularity is not >>>> even PostgreSQL's goal, but I am sure a bit more would be welcome. >>> >>> Does MySQL have a monolithic distribution? >> >> Well obviously MySQL is missing alot of functionality that you will >> not get in any version of MySQL though. >> >> However it comes with replication, fulltext indexes out of the box. >> They currently only have a single stored procedure language (partial >> SQL:2003 implementation). > > Oh and they also ship a federated (AFAIK their dblink answer) along with > several other storage engines for various specific tasks. Since I appreantly like monologs .. MySQL also has other features that are not available via pgfoundery like being able to determine the default charset on the database, table and column level, as well as COLLATE support to determine the sort order at runtime. Anyways what I want to make clear is simply that there are plenty of features that come with the default distro of other RDBMS that are only available via the pgfoundery. There are also plenty of features available in pgfoundry not available in any other RDBMS. However newbies that evaluate which RDBMS to use will probably never know. regards, Lukas
Lukas Smith wrote: > > Since I appreantly like monologs .. MySQL also has other features that > are not available via pgfoundery like being able to determine the > default charset on the database, table and column level, as well as > COLLATE support to determine the sort order at runtime. > > Anyways what I want to make clear is simply that there are plenty of > features that come with the default distro of other RDBMS that are > only available via the pgfoundery. There are also plenty of features > available in pgfoundry not available in any other RDBMS. However > newbies that evaluate which RDBMS to use will probably never know. > None of these is really connected in any way with any sort of modularisation. When we get table and column level charset and collation support it will surely be in the core, and not in an addon module. The topic here is NOT what features are missing from postgres. Oh, and we *do* have per database charsets. cheers andrew
Andrew Dunstan wrote: > > The topic here is NOT what features are missing from postgres. > Of course it is ;-) Regards, Thomas Hallgren
Peter Eisentraut wrote: > Joshua D. Drake wrote: >> For example there is NOT an PostgreSQL 8.1 for Ubuntu Breezy. > > http://packages.ubuntu.com/breezy-backports/misc/ Thanks Peter :), I knew about backports but didn't know what was in there. But what about when 8.2 comes out? Doubtful that they will release for breezy because a new version of Ubuntu will be out by then. Example, Hoary doesn't have 8.1 available :) Sincerely, Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
> Since I appreantly like monologs .. MySQL also has other features that > are not available via pgfoundery like being able to determine the > default charset on the database, table and column level, as well as > COLLATE support to determine the sort order at runtime. SHOW ALL; ? > > Anyways what I want to make clear is simply that there are plenty of > features that come with the default distro of other RDBMS that are only > available via the pgfoundery. There are also plenty of features > available in pgfoundry not available in any other RDBMS. However newbies > that evaluate which RDBMS to use will probably never know. > > regards, > Lukas > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Hi, Bruce Momjian írta: > There are roughly three weeks left until the feature freeze on August 1. > If people are working on items, they should be announced before August > 1, and the patches submitted by August 1. If the patch is large, it > should be discussed now and an intermediate patch posted to the lists > soon. > > FYI, we don't have many major features ready for 8.2. > > -- > Bruce Momjian bruce@momjian.us > EnterpriseDB http://www.enterprisedb.com > I am working on adding a new column contraint, namely the GENERATED [ALWAYS | BY DEFAULT ] AS [ IDENTITY ( sequence_options ) | ( expression )] I surely won't be ready by August 1 as I am going on a holiday this weekend for two weeks. Anyway, I submit what I have in my hands now and describe what it does and what lacks. Maybe someone can fill the missing gaps, I didn't have too much time to dig deeper in the PostgreSQL code. Lacks: - proper sgml documentation - pg_dump support - GENERATED ALWAYS doesn't work (yet[*]) - ALTER TABLE support What works: - GENERATED ... AS IDENTITY creates the sequence with the given parameters - any data types that has an implicit cast from int8 can be defined as GENERATED ... AS IDENTITY DEFAULT and GENERATED are mutually exclusive and I tweaked gram.y to make it so and GENERATED ... is now parsed as a column constraint. Unfortunately I introduced one shift/reduce conflict and I don't see a way to solve it. SQL2003 says that only one IDENTITY column may exist in a table, I didn't make a check for that, it may be useful to allow more than one. Also, the parsing is very simplistic, it allows GENERATED BY DEFAULT AS ( expr ) and I made it to behave exactly like DEFAULT. It can be eliminated in the parser, though. Tom Lane was unhappy with my previous attempt as it introduced SERIAL, SERIAL4, SERIAL8 and BIGSERIAL as keywords. This time I kept it the way PostgreSQL always had. [*] I introduced a new column attribute (attforceddef) and it could be used in rewriteHandler.c to override given data with the default for GENERATED ALWAYS column. I must have missed some places where I have to assign ColumnDef->force_default to FormData_pg_attribute->attforceddef or vice-versa but I am certain that not too many left. Needless to say it passes "make check". Please, review and point out my mistakes again. :-) Best regards, Zoltán Böszörményi
Attachment
Zoltan Boszormenyi <zboszor@dunaweb.hu> writes:
> I am working on adding a new column contraint,
> namely the GENERATED [ALWAYS | BY DEFAULT ] AS
> [ IDENTITY ( sequence_options ) | ( expression )]
Doesn't this still have the issue that we're taking over spec-defined
syntax to represent behavior that does not quite match the spec-defined
semantics? It's not clear to me how closely tied this syntax is to
NEXT VALUE FOR, but if it's got any of the latter's action-at-a-distance
subtleties then I think we ought to leave well enough alone till we have
a solution for that.
regards, tom lane
Lukas, all: > So what I am suggesting is that PostgreSQL.org should push people > towards the monolithic distro. The docs should contain everything that > is in the monolithic distro. At conference we should say the name of the > monolithic distro etc. The issue I think you're ignoring is that maintaining such a distro and its build system for a reasonable number of platforms would require an enormous amount of work ... like, 3-4 full-time developers and at least a dozen part-time developers. Compare the staff requirements for Debian, Red Hat or SuSE. I can tell you from being the Bizgres admin for a few months that just trying to maintain/debug a build system that would do PostgreSQL + JasperReports + KETL + 4 optional modules on four platforms was easily 20-30 hours of work, *per release*. So this isn't something we can just vote into existance. Second with "endorsing" or "certifying" projects on pgFoundry and elsewhere, who has the time? To rate stuff as mature/not mature a committee of PostgreSQL people would have to be constantly reviewing projects, every single month, and probably getting into long political debates to boot. If we do less, a repeat of the libpq++/libpqxx mess is inevitable. It's very nice to throw these things out there and put them on the TODO list ... and if I had $100,000 in development money to throw at something, I might spend it that way ... but to propose them as *immediate* solutions to problems for 8.2 is fantasy. -- Josh Berkus PostgreSQL @ Sun San Francisco
Josh Berkus wrote: > It's very nice to throw these things out there and put them on the TODO > list ... and if I had $100,000 in development money to throw at something, I > might spend it that way ... but to propose them as *immediate* solutions to > problems for 8.2 is fantasy. Point taken. Obviously I was not suggesting this for 8.2 .. it was more a suggestion for the midterm. I never installed Bizgres or Mammoth PostgreSQL. Maybe however there could be some lobbying from PostgreSQL core to better pool the resources currently directed at these two forks (and other similar efforts). That being said, I am just a talker here that is hoping to instigate action by others and we all know talk is cheap. regards, Lukas
Bruce Momjian wrote: > Mario Weilguni wrote: > > Will this patch make it into 8.2? > > http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php > > > > It's a really nice feature, would be extremly useful with tools like pgpool. > > No, it will not because RESET CONNECTION can mess up interface code that > doesn't want the connection reset. We are not sure how to handle that. Hmm, what interface code are you talking about? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
> > > Will this patch make it into 8.2? > > > http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php > > > > > > It's a really nice feature, would be extremly useful with tools like pgpool. > > > > No, it will not because RESET CONNECTION can mess up interface code > > that doesn't want the connection reset. We are not sure how to handle that. Imho, if it where at the protocol level, that would not be such an issue. If the interface gives access to the protocol level it is already depending on good will. Andreas
Alvaro Herrera wrote: > Bruce Momjian wrote: > > Mario Weilguni wrote: > > > Will this patch make it into 8.2? > > > http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php > > > > > > It's a really nice feature, would be extremly useful with tools like pgpool. > > > > No, it will not because RESET CONNECTION can mess up interface code that > > doesn't want the connection reset. We are not sure how to handle that. > > Hmm, what interface code are you talking about? I believe JDBC, for example, sets things inside the interface that would be broken by RESET CONNECTION. Here is a thread about it: http://archives.postgresql.org/pgsql-patches/2005-01/msg00029.php -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Tatsuo Ishii wrote: > I'm disappointed. > > Can you point out past discussion for this? Yes: http://archives.postgresql.org/pgsql-patches/2005-01/msg00029.php --------------------------------------------------------------------------- > -- > Tatsuo Ishii > SRA OSS, Inc. Japan > > > Mario Weilguni wrote: > > > Will this patch make it into 8.2? > > > http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php > > > > > > It's a really nice feature, would be extremly useful with tools like pgpool. > > > > No, it will not because RESET CONNECTION can mess up interface code that > > doesn't want the connection reset. We are not sure how to handle that. > > > > --------------------------------------------------------------------------- > > > > > > > > > > Am Freitag, 7. Juli 2006 19:13 schrieb Bruce Momjian: > > > > There are roughly three weeks left until the feature freeze on August 1. > > > > If people are working on items, they should be announced before August > > > > 1, and the patches submitted by August 1. If the patch is large, it > > > > should be discussed now and an intermediate patch posted to the lists > > > > soon. > > > > > > > > FYI, we don't have many major features ready for 8.2. > > > > > > > > -- > > > > Bruce Momjian bruce@momjian.us > > > > EnterpriseDB http://www.enterprisedb.com > > > > > > > > + If your life is a hard drive, Christ can be your backup. + > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > > > TIP 5: don't forget to increase your free space map settings > > > > > > ---------------------------(end of broadcast)--------------------------- > > > TIP 1: if posting/reading through Usenet, please send an appropriate > > > subscribe-nomail command to majordomo@postgresql.org so that your > > > message can get through to the mailing list cleanly > > > > -- > > Bruce Momjian bruce@momjian.us > > EnterpriseDB http://www.enterprisedb.com > > > > + If your life is a hard drive, Christ can be your backup. + > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 9: In versions below 8.0, the planner will ignore your desire to > > choose an index scan if your joining column's datatypes do not > > match > > -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
> Alvaro Herrera wrote: > > Bruce Momjian wrote: > > > Mario Weilguni wrote: > > > > Will this patch make it into 8.2? > > > > http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php > > > > > > > > It's a really nice feature, would be extremly useful with tools like pgpool. > > > > > > No, it will not because RESET CONNECTION can mess up interface code that > > > doesn't want the connection reset. We are not sure how to handle that. > > > > Hmm, what interface code are you talking about? > > I believe JDBC, for example, sets things inside the interface that would > be broken by RESET CONNECTION. Here is a thread about it: > > http://archives.postgresql.org/pgsql-patches/2005-01/msg00029.php I think we had similar problem with client encoding and solved it by using parameter status. Why don't we solve the JDBC problem in the same way? -- Tatsuo Ishii SRA OSS, Inc. Japan
Tatsuo Ishii wrote: > > Alvaro Herrera wrote: > > > Bruce Momjian wrote: > > > > Mario Weilguni wrote: > > > > > Will this patch make it into 8.2? > > > > > http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php > > > > > > > > > > It's a really nice feature, would be extremly useful with tools like pgpool. > > > > > > > > No, it will not because RESET CONNECTION can mess up interface code that > > > > doesn't want the connection reset. We are not sure how to handle that. > > > > > > Hmm, what interface code are you talking about? > > > > I believe JDBC, for example, sets things inside the interface that would > > be broken by RESET CONNECTION. Here is a thread about it: > > > > http://archives.postgresql.org/pgsql-patches/2005-01/msg00029.php > > I think we had similar problem with client encoding and solved it by > using parameter status. Why don't we solve the JDBC problem in the > same way? Oh, yes, we could do that. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Hi, Tom Lane írta: > Zoltan Boszormenyi <zboszor@dunaweb.hu> writes: > >> I am working on adding a new column contraint, >> namely the GENERATED [ALWAYS | BY DEFAULT ] AS >> [ IDENTITY ( sequence_options ) | ( expression )] >> > > Doesn't this still have the issue that we're taking over spec-defined > syntax to represent behavior that does not quite match the spec-defined > semantics? It's not clear to me how closely tied this syntax is to > NEXT VALUE FOR, but if it's got any of the latter's action-at-a-distance > subtleties then I think we ought to leave well enough alone till we have > a solution for that. > > regards, tom lane > Sorry for not answering earlier, I was on a holiday. I read again sections 6.13 and 9.21 about NEXT VALUE FOR and generation of the next value of a sequence generator, respectively. If I see it right, neither of them require the other one. The IDENTITY COLUMN syntax in section 11.4 only mentions section 9.21. Section 14.8 about INSERT statement does not even mention it, only refers to "default clause" in section 11.5. And that also doesn't say anything about neither NEXT VALUE FOR nor next value generation of a sequence. And I saw comments in the PostgreSQL documentation that goes like this: "Standard doesn't specify so we are conforming." Hint, hint. ;-) I think the IDENTITY COLUMN (and GENERATED ALWAYS AS) can stand on its own without NEXT VALUE FOR. Best regards, Zoltán Böszörményi