Re: [HACKERS] Three weeks left until feature freeze
Hi, Tom Lane írta: Zoltan Boszormenyi [EMAIL PROTECTED] 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 ---(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
Re: [HACKERS] Three weeks left until feature freeze
Ü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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
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 [EMAIL PROTECTED] EnterpriseDBhttp://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 psql-serial-8.diff.gz Description: Unix tar archive ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
Zoltan Boszormenyi [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
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 solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
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 ---(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
Re: [HACKERS] Three weeks left until feature freeze
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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
* Joshua D. Drake ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] Three weeks left until feature freeze
On 7/12/06, Tom Lane [EMAIL PROTECTED] 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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
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. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Three weeks left until feature freeze
Dave Cramer [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
On 7/13/06, Dave Cramer [EMAIL PROTECTED] 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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(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
Re: [HACKERS] Three weeks left until feature freeze
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 -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | 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 bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
On 7/13/06, Dave Cramer [EMAIL PROTECTED] 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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(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
Re: [HACKERS] Three weeks left until feature freeze
On 13-Jul-06, at 9:29 AM, Jonah H. Harris wrote: On 7/12/06, Tom Lane [EMAIL PROTECTED] 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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
Tom Lane wrote: Dave Cramer [EMAIL PROTECTED] 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 [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Three weeks left until feature freeze
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. -- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
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. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
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). ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
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 -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | 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 bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
On 7/13/06, Tom Lane [EMAIL PROTECTED] 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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Three weeks left until feature freeze
[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
On 13-Jul-06, at 1:02 PM, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 ---(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
Re: [HACKERS] Three weeks left until feature freeze
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 solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
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 [EMAIL PROTECTED] 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 solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Three weeks left until feature freeze
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 solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
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 solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Three weeks left until feature freeze
Tom Lane wrote: Dave Cramer [EMAIL PROTECTED] 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 ---(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
Re: [HACKERS] Three weeks left until feature freeze
-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 [EMAIL PROTECTED] 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- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
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/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
Jonah H. Harris [EMAIL PROTECTED] 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 ---(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
Re: [HACKERS] Three weeks left until feature freeze
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
-Original Message- From: Jonah H. Harris [EMAIL PROTECTED] To: Josh Berkus josh@agliodbs.com Cc: Thomas Hallgren [EMAIL PROTECTED]; Dave Cramer [EMAIL PROTECTED]; David Fetter [EMAIL PROTECTED]; Satoshi Nagayasu [EMAIL PROTECTED]; Tom Lane [EMAIL PROTECTED]; 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
Andrew Dunstan wrote: Tom Lane wrote: Dave Cramer [EMAIL PROTECTED] 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 solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Three weeks left until feature freeze
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 -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | 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 bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
* Joshua D. Drake ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] Three weeks left until feature freeze
Bruce, On 7/7/06 10:13 AM, Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Three weeks left until feature freeze
[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
On 7/13/06, Tom Lane [EMAIL PROTECTED] 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. 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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
[EMAIL PROTECTED] 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 solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
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 plspacejava, 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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Three weeks left until feature freeze
On 7/13/06, Marc G. Fournier [EMAIL PROTECTED] 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 plspacejava, 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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
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 solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
On Thu, 13 Jul 2006, Jonah H. Harris wrote: On 7/13/06, Dave Cramer [EMAIL PROTECTED] 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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
On 7/13/06, Marc G. Fournier [EMAIL PROTECTED] 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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
On 7/13/06, Marc G. Fournier [EMAIL PROTECTED] 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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
Jonah H. Harris [EMAIL PROTECTED] writes: On 7/13/06, Marc G. Fournier [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
-Original Message- From: Marc G. Fournier [EMAIL PROTECTED] To: Rod Taylor [EMAIL PROTECTED] Cc: Jonah H. Harris [EMAIL PROTECTED]; 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'll soon start killing dead projects, and migrating others. /D ---(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
Re: [HACKERS] Three weeks left until feature freeze
On 7/13/06, Marc G. Fournier [EMAIL PROTECTED] 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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
On 7/13/06, Tom Lane [EMAIL PROTECTED] 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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- === 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/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
Jonah H. Harris wrote: On 7/13/06, Marc G. Fournier [EMAIL PROTECTED] 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 solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -- === 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/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Three weeks left until feature freeze
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 solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
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.
--
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/
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
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 [EMAIL PROTECTED] EnterpriseDBhttp://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
Re: [HACKERS] Three weeks left until feature freeze
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
On Thu, 13 Jul 2006 16:15:04 -0500 (EST) Kris Jurka [EMAIL PROTECTED] 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. ---(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
Re: [HACKERS] Three weeks left until feature freeze
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 ---(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
Re: [HACKERS] Three weeks left until feature freeze
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Three weeks left until feature freeze
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Three weeks left until feature freeze
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. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
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? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
On Thu, 13 Jul 2006 19:54:19 -0300 (ADT) Marc G. Fournier [EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
On Thu, 13 Jul 2006, D'Arcy J.M. Cain wrote: On Thu, 13 Jul 2006 19:54:19 -0300 (ADT) Marc G. Fournier [EMAIL PROTECTED] 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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Three weeks left until feature freeze
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 [EMAIL PROTECTED] Phone: +81-3-3523-8122 ---(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
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 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 solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED]
Yahoo . yscrappy Skype: hub.orgICQ . 7615664
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Three weeks left until feature freeze
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
RPM packaging (was :Re: [HACKERS] Three weeks left until feature freeze)
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/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Three weeks left until feature freeze
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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
On Thu, 13 Jul 2006, Jonah H. Harris wrote: On 7/13/06, Tom Lane [EMAIL PROTECTED] 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 . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 [EMAIL PROTECTED] EnterpriseDBhttp://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
Re: [HACKERS] Three weeks left until feature freeze
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: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
