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
[HACKERS] postgresql.conf basic analysis tool
Is there any interest in a basic perl script that would read through a postgresql.conf file and calculate approximate memory (and shared memory) usage? Also, are there any other (simple for now) things I should look at in the process? Asking because I'm getting annoyed with doing this by hand so... Drew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pre_load_libraries
On Wed, Jul 12, 2006 at 06:47:56PM -0700, Marc Munro wrote: On a related note, I can see no way to release Veil's shared memory segment when postgres is shut down. Perhaps I should be thinking about making the management of such shared memory segments something that postgres does on behalf of its add-ins, though that seems presumptious. The easiest way is to simply delete the shared memory segment after you've done the shmat(). The shmat() will hold onto it until postgres quits and then be cleaned up by the OS. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] Implied Functional Index use
- add a new boolean to pg_operator to allow us to define which operators offer true equality ... This would be useful for other purposes too, as we keep coming up against what's the equality operator for this datatype problems. However, the restriction to true equality, such that we can assume x = y implies f(x) = f(y) for every immutable function f on the datatype Maybe we could have a tri (or more) state flag for the equality operators. ' ' .. not an equality op 'e' .. equality 's' .. strict equality (op only true iff the binary representation is equal) Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Implied Functional Index use
On Wed, 2006-07-12 at 22:34 -0400, Tom Lane wrote: More generally, I don't believe in hacks that only work for a small number of built-in types: to me, that's prima facie evidence that you haven't thought the problem through. I agree an attempt at a simple definition of the required functional properties hasn't yielded a great solution, so we must go deeper. On Wed, 2006-07-12 at 15:09 +0200, Peter Eisentraut wrote: From a mathematical point of view, it seems cleaner to attach this property to functions, not operators, namely, this function preserves the following relations. This would allow extending Simon's idea to other operators such as and and possibly more mind-boggling cases with geometric operators and such. Well, in PG, operators are functions that define various special properties of their inputs/outputs, so it seems the correct place to put these definitions. I agree it seems more normalised to place this information at the function itself, but that is not current precedent. On Thu, 2006-07-13 at 09:14 +0200, Zeugswetter Andreas DCP SD wrote: Maybe we could have a tri (or more) state flag for the equality operators. ' ' .. not an equality op 'e' .. equality 's' .. strict equality (op only true iff the binary representation is equal) Tom has pointed out that the required functional properties are actually a fourth state between equality and full binary equality. I was trying to avoid introducing new single-use properties, but I think that is the only way here. My concern was not the complexity of specifying this for function authors, but the problem of making an incorrect selection leading to incorrect query results. It seems we need this in the catalog: ' ' .. not an equality op 'e' .. equality (sufficient for FKs) 'f' .. functional equality (sufficient for this proposed optimisation) 's' .. strict equality (op only true iff the binary representation is equal) We're breaking new ground here, but that's a good thing. I'd much rather have an optimisable and extensible type system than a hard-wired one. There is a problem of implication here, AFAICS: When a user SQL asks WHERE col1 = 7 which equality level is meant when several exist? We currently already assume that they mean e-equality, since it is the most useful and intuitive meaning. That is not as strict as f-equality, so we would not be able to make implications from that. I'll think on this some more, but not for 8.2. -- Simon Riggs EnterpriseDB 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
[HACKERS] RESET CONNECTION?
Will this patch make it into 8.2? http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php It's a really nice feature, would be extremly useful with tools like pgpool. Am Freitag, 7. Juli 2006 19:13 schrieb Bruce Momjian: There are roughly three weeks left until the feature freeze on August 1. If people are working on items, they should be announced before August 1, and the patches submitted by August 1. If the patch is large, it should be discussed now and an intermediate patch posted to the lists soon. FYI, we don't have many major features ready for 8.2. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL
Tatsuo Ishii [EMAIL PROTECTED] writes: Interesting. We (some Japanese companies including SRA OSS, Inc. Japan) did some PG scalability testing using a Unisys's big 16 (physical) CPU machine and found PG scales up to 8 CPUs. However beyond 8 CPU PG does not scale anymore. The result can be viewed at OSS iPedia web site (http://ossipedia.ipa.go.jp). Our conclusion was PG has a serious lock contention problem in the environment by analyzing the oprofile result. 18% in s_lock is definitely bad :-(. Were you able to determine which LWLock(s) are accounting for the contention? Yes. We were interested in that too. Some people did addtional tests to determin that. I don't have the report handy now. I will report back next week. Sorry for the delay. Finally I got the oprofile data. It's huge(34MB). If you are interested, I can put somewhere. Please let me know. -- Tatsuo Ishii SRA OSS, Inc. Japan ---(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] Implied Functional Index use
There is a problem of implication here, AFAICS:
When a user SQL asks
WHERE col1 = 7
which equality level is meant when several exist?
Well, the operator must be unique, so there is no problem.
Unique in the sense that an operator with the same name ('=' in this
case)
and argument types cannot exist for more than one level of equality.
(and the level should not have an effect on the resolution)
So, when we see col1 = 7 we lookup the equality level of the operator
and decide whether it is strict enough for the particular optimization.
Andreas
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] postgresql.conf basic analysis tool
Andrew, Josh did something like this and I wrote some java to do some of it. It's in a project called pgconfigurator (I think) dave On 12-Jul-06, at 2:46 PM, Andrew Hammond wrote: Is there any interest in a basic perl script that would read through a postgresql.conf file and calculate approximate memory (and shared memory) usage? Also, are there any other (simple for now) things I should look at in the process? Asking because I'm getting annoyed with doing this by hand so... Drew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
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
[HACKERS] Fwd: Three weeks left until feature freeze
Forwarded to -hackers. Jonah H. Harris wrote: Again, I guess it comes down to what we're willing to let go. If we want new users who want certain functionality in the system to be happy, we include it. Otherwise, we do as we do now, keeping tons of projects on pgfoundry and hoping a user doesn't just pass us by because they installed PostgreSQL and didn't see the things they want/need in the core. Of course, this will last until MySQL goes ahead and adds a Java PL and the user doesn't even glance over at us... but I guess that falls back to the argument of, what kind of user do we really want. Almost everyone here who's ever done real-world consulting on PostgreSQL has run into PL/Java at some point in time, so it is used and used often. Aside from obviously the big issue of who maintains all the pgfoundry stuff, I also think that the PostgreSQL family would benefit from a distribution that is more and the kitchen sink style. I do not know exactly if Bizgres could be considered just that? Or maybe it could get promoted to be that? What I mean is I think it makes absolute sense to keep a very stable, very well maintained core PostgreSQL distribution which is that anyone should base their distributions on. However I do think that PostgreSQL is missing out in getting new users aboard that are in the early stages of evalutation and simply only consider features that they get along with a default installation (mostly due to lack of better knowledge about places like pgfoundry). For these kinds of users it would make sense to provide a distro that has an extended feature list, while sacrificing maybe a tiny bit of stability because it adds modules that do not adhere to the same high level of maintaince as PostgreSQL core does. regards, Lukas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL
Tatsuo Ishii [EMAIL PROTECTED] writes: 18% in s_lock is definitely bad :-(. Were you able to determine which LWLock(s) are accounting for the contention? Yes. We were interested in that too. Some people did addtional tests to determin that. I don't have the report handy now. I will report back next week. Sorry for the delay. Finally I got the oprofile data. It's huge(34MB). If you are interested, I can put somewhere. Please let me know. Yes, please. 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
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] Fwd: Three weeks left until feature freeze
Am Donnerstag, 13. Juli 2006 16:48 schrieb Jonah H. Harris: What I mean is I think it makes absolute sense to keep a very stable, very well maintained core PostgreSQL distribution which is that anyone should base their distributions on. I don't want to get into an operating system bout here, but there are a number of systems out there that include a fair amount of PostgreSQL-related software in packaged and readily available form, and will accept your contribution if anything is missing. I seriously doubt that providing one big PostgreSQL *source* distribution will help that process in any way. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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
[HACKERS] New shared memory hooks proposal (was Re: pre_load_libraries)
On Thu, 2006-07-13 at 01:13 -0300, Tom Lane wrote: Marc Munro [EMAIL PROTECTED] writes: ... A better solution from my point of view would be to simply move the call to process_preload_libraries to a point after shared memory has been set up. Is there some reason this could not be done? That would make it impossible for a preloaded library to request any shared memory of its own --- something that admittedly we don't have a hook to support, but do we want to foreclose it permanently? That does sound like the right way to go. Here is my new proposal: Add-ins register their requirement for shared memory using a new function: RegisterShmemRequirement(char *context_name, int size). This would be called by the init function called from process_preload_libraries. When shared memory is initialised, extra space is allocated for each registered add-in. Each add-in's registered allocation is a separate memory context identified by the context_name parameter provided during registration. Add-ins allocate shared memory from their own context using a new function ShemAddinAlloc(), which adds the context_name parameter to the normal ShemAlloc parameter list. This would save add-ins from having to manage their own shared memory segements while providing a degree of separation and isolation so that one add-in could not exhaust the shared memory of another or of the backend. If this is acceptable, I think it is within my skill level to implement. Comments? __ Marc signature.asc Description: This is a digitally signed message part
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] Updateable views for 8.2 or 8.3?
--On Mittwoch, Juli 12, 2006 20:58:08 -0500 Jaime Casanova [EMAIL PROTECTED] wrote: if nobody step up i can do the list. i think this is the last patch that he post: http://archives.postgresql.org/pgsql-hackers/2006-03/msg00586.php The code drifted since then in some parts. I'll sent a new version to -patches soon. i will try to rebuild a test script have made for this... That would be cool. -- Thanks Bernd ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Fwd: [pgsql-hackers-win32] Build with Visual Studio MSVC
I just recently came to know that geocities.com is down. It is accessible from geocities.yahoo.com though, but my site is still not accessible. I had deleted my local copy, relying on the gecities, and almost lost it; but then I twisted some knobs in geocities.yahoo.com to get the file back... Since I almost lost it, I thought it'd be a good idea to mail it across to everyone this time, so that there is at least one source when needed!!! Regards, Gurjeet. On 5/15/06, Thomas Hallgren [EMAIL PROTECTED] wrote: Josh, I'm the lead architect of the Eclipse Buckminster project (www.eclipse.org/buckminster). I'd be happy to help the guys from data tools with PostgreSQL if there's anything I can do. Not sure what that would be though. Which Mike is it you're referring to? Regards, Thomas Hallgren Gurjeet Singh wrote: No I am not... I used Eclipse for the first time just last week. But yes, I wish to contribute to the CDT plugin. I think their Indexer is a bit slow... it takes more than an hour (about two hours) to index postgres' source code!!! Also, I just noticed that the background gdb crashes when trying to open an uninitialized structure in the 'Variables' view. If you are talking about, Mike Taylor from Eclipse, (http://www.eclipse.org/org/elections/candidate.php?year=2006id=mtaylor), then I'd be delighted to get in touch with him and see if Postgres and Eclipse can work more closely. Gurjeet. On 5/15/06, Josh Berkus josh@agliodbs.com wrote: Gurjeet, I know it has been over a week now since I said that I'll put together a document that describes how to debug postgres using Eclipse IDE on Windows. I have finally completed the first draft and uploaded it here: Hey, are you a member of the Eclipse Project? Mike was bugging me a few months ago about wanting more involvement by PostgreSQL people in their Data Tools project. -- Josh Berkus Aglio Database Solutions San Francisco pg_on_eclipse.gz Description: GNU Zip compressed data ---(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, 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] Updateable views for 8.2 or 8.3?
--On Mittwoch, Juli 12, 2006 09:30:38 -0700 Joe Conway [EMAIL PROTECTED] wrote: Jaime Casanova wrote: is anybody working on the Bernd Helmle's updateable views patch? or know what the status of this is? I'm still working on this and trying to get all open issues done for 8.2 feature freeze. I was just wondering about this also. If no one else is working on it, I'd like to try to push it through to completion for 8.2 myself. Can anyone summarize what the open issues are? The main issues currently are to clean up the code and do the documentation, all functional parts of the patch should be complete (read: it supports the SQL92 spec). -- Thanks Bernd ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
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] Fwd: Three weeks left until feature freeze
Aside from obviously the big issue of who maintains all the pgfoundry stuff, I also think that the PostgreSQL family would benefit from a distribution that is more and the kitchen sink style. I do not know exactly if Bizgres could be considered just that? Or maybe it could get promoted to be that? Lukas, that is what www.mammothpostgresql.org is :) Sincerely, Joshua D. Drake What I mean is I think it makes absolute sense to keep a very stable, very well maintained core PostgreSQL distribution which is that anyone should base their distributions on. However I do think that PostgreSQL is missing out in getting new users aboard that are in the early stages of evalutation and simply only consider features that they get along with a default installation (mostly due to lack of better knowledge about places like pgfoundry). For these kinds of users it would make sense to provide a distro that has an extended feature list, while sacrificing maybe a tiny bit of stability because it adds modules that do not adhere to the same high level of maintaince as PostgreSQL core does. regards, Lukas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL 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
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
[HACKERS] Speed check II
Just confirming that its fixed ... 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
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
[HACKERS] Proper Method for using LockAcquire
Hi All,
I've been working on a small module that I will be pluging into my
local PostreSQL 8.x database and am in need of doing some table locking.
At this time, I've used various other examples to no avail and was
wondering what the proper method for aquiring a table lock within the
module would be?
For example I am using an SPI based module:
static void mytest(void) {
LOCKMETHODIDlocalLockTableId = INVALID_LOCKMETHOD;
LOCKTAG localtag;
memset(localtag, 0, sizeof(localtag));
localtag.relId = XactLockTableId;
localtag.dbId = 1;
localtag.objId.xid = InvalidTransactionId;
if (!LockAcquire(LocalLockTableId, localtag,
GetCurrentTransactionId(), Sharelock, false)) {
elog(ERROR, mytest: did not acquire table lock);
}
if(!LockRelease(LocalLockTableId, localtag,
GetCurrentTransactionId(), Sharelock)) {
elog(ERROR, mytest: could not release lock);
}
}
I know there is something I am missing and would appreciate any help. I
believe I need to initialize the LocalLockTableId, but I have not been
able to find any examples of that being done. Could someone look this
over and point me in the right direction?
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] Updateable views for 8.2 or 8.3?
On 7/13/06, Bernd Helmle [EMAIL PROTECTED] wrote: I'm still working on this and trying to get all open issues done for 8.2 feature freeze. Sweet! -- 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
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
[HACKERS] buildfarm future
I intended to post this anyway as a followup to the conference session,
but I have been spurred to do it nowby the Pl/J(ava) discussion.
I outlined a number of possible directions for buildfarm, and we had a
good discussion.
Based on that, my current intention is to make provision for the
following, and pretty much in this order:
. an optional pgbench run at the end of each buildfarm run, plus
supporting web page to plot stats
. clean and release web code
. extra core/contrib/PL regression tests that come with the core
distribution but are not done by make {check, installcheck}
. extra core regression tests that are not in the core distribution
(maybe download from pgfoundry)
. support for non-core projects - initially for slony-1 (because they
asked me about it ages ago).
In connection with the last item, Thomas asked me at the conference to
consider a setup for PL/Java. If, as I suspect, we end up with something
similar to the status quo, I will certainly do so, but it might be a while.
If anyone with some good perl skill wants to jump in and help they will
be welcome.
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] Proper Method for using LockAcquire
Chris Bowlby [EMAIL PROTECTED] writes: I've been working on a small module that I will be pluging into my local PostreSQL 8.x database and am in need of doing some table locking. At this time, I've used various other examples to no avail and was wondering what the proper method for aquiring a table lock within the module would be? You should not be touching locks at any level lower than lmgr.c's exports; eg LockRelation() not LockAcquire(). The LockAcquire API is not as stable. Usually people take a relation lock in combination with opening the rel in the first place, ie, specify the desired lock to heap_open or relation_open or one of their variants. If you apply LockRelation() to an already-opened rel then you need to be worrying about possible deadlocks due to lock upgrading. Also, 90% of the time you probably don't want to release the lock explicitly at all; leave it to be held until transaction end. Early release violates the 2PL principle, so you need to analyze things pretty carefully to determine if it's safe. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Proper Method for using LockAcquire
On Thu, Jul 13, 2006 at 03:01:31PM -0300, Chris Bowlby wrote: Hi All, I've been working on a small module that I will be pluging into my local PostreSQL 8.x database and am in need of doing some table locking. At this time, I've used various other examples to no avail and was wondering what the proper method for aquiring a table lock within the module would be? Firstly, why? Most operations in PostgreSQL acquire the appropriate locks for you, so you don't need to do it yourself. Explicit locking opens you up to deadlocks. Secondly, what's wrong with LockRelation(rel, lockmode)? I grabbed that from relation_open in access/heap/heapam.c. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
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
[HACKERS] AIX buildfarm failure
I am seeing buildfarm failures on AIX because stdio.h is being included before pg_config.h (which has the definition of _LARGE_FILES). The problem is stemming from math.h including stdlib.h, which (after several more inclusions) ends up including stdio.h. This is where the fgetpos64 different definitions is coming from. If I move math.h down after postgres.h in nodeHash.c, the problem goes away. Do we want to consider putting math.h into the standard include set? Or is there a general rule that postgres.h needs to be the first include file (before system headers, etc)? Thanks, -rocco ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] 8.2 features?
What is the state of the following items that have been previously discussed? . MERGE (at least in PK case) . multiple values clauses for INSERT . recursive WITH queries Thanks andrew ---(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] Fwd: Three weeks left until feature freeze
On Thu, 13 Jul 2006, Jonah H. Harris wrote: Aside from obviously the big issue of who maintains all the pgfoundry stuff, I also think that the PostgreSQL family would benefit from a distribution that is more and the kitchen sink style. This has been suggested before ... nobody seems to want to 'run with it'/coordinate it though ... maybe that, in itself, is argument enough against doing it, only a small number of ppl *really* care/want it, and those ones aren't willing to put forth the energy required to do it ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [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
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] Fwd: Three weeks left until feature freeze
On Thu, 13 Jul 2006, Joshua D. Drake wrote: Aside from obviously the big issue of who maintains all the pgfoundry stuff, I also think that the PostgreSQL family would benefit from a distribution that is more and the kitchen sink style. I do not know exactly if Bizgres could be considered just that? Or maybe it could get promoted to be that? Lukas, that is what www.mammothpostgresql.org is :) Then *it* needs to be promoted more, since this is actually the first I'd heard of it :( Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [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: 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] 8.2 features?
Andrew Dunstan [EMAIL PROTECTED] writes: What is the state of the following items that have been previously discussed? . MERGE (at least in PK case) No submitted patch; no one working on it AFAIK; doesn't look like something that could get done in the next three weeks. . multiple values clauses for INSERT Also not done, but if we are willing to accept a limited patch (ie, not necessarily everything that SQL92 says you can do with VALUES, but at least the INSERT case) I think it could get done. I might even volunteer to do it ... but won't object if someone else volunteers to. . recursive WITH queries I believe Jonah has given up on fixing the originally-submitted patch, but he mentioned at the code sprint that non-recursive WITH is potentially doable in time for 8.2. Not sure if that's a sufficiently important case to be worth doing. regards, tom lane ---(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
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] Fwd: Three weeks left until feature freeze
Marc G. Fournier wrote: On Thu, 13 Jul 2006, Jonah H. Harris wrote: Aside from obviously the big issue of who maintains all the pgfoundry stuff, I also think that the PostgreSQL family would benefit from a distribution that is more and the kitchen sink style. This has been suggested before ... nobody seems to want to 'run with it'/coordinate it though ... maybe that, in itself, is argument enough against doing it, only a small number of ppl *really* care/want it, and those ones aren't willing to put forth the energy required to do it ... I repeat: www.mammothpostgresql.org :) Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [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 2: Don't 'kill -9' the postmaster
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] AIX buildfarm failure
Rocco Altier [EMAIL PROTECTED] writes: If I move math.h down after postgres.h in nodeHash.c, the problem goes away. Bruce, you broke it. Have you forgotten the fundamental inclusion rule? postgres.h (or postgres_fe.h, or c.h) first, then system headers, then our own other headers. 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] Fwd: Three weeks left until feature freeze
Marc G. Fournier wrote: On Thu, 13 Jul 2006, Joshua D. Drake wrote: Aside from obviously the big issue of who maintains all the pgfoundry stuff, I also think that the PostgreSQL family would benefit from a distribution that is more and the kitchen sink style. I do not know exactly if Bizgres could be considered just that? Or maybe it could get promoted to be that? Lukas, that is what www.mammothpostgresql.org is :) Then *it* needs to be promoted more, since this is actually the first I'd heard of it :( Were trying man :) I have people building for most major distributions at this point. We should have FreeBSD soon, as well as MacOSX. Sincerely, Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [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 6: explain analyze is your friend
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] 8.2 features?
On 7/13/06, Tom Lane [EMAIL PROTECTED] wrote: . recursive WITH queries I believe Jonah has given up on fixing the originally-submitted patch, but he mentioned at the code sprint that non-recursive WITH is potentially doable in time for 8.2. Not sure if that's a sufficiently important case to be worth doing. A working WITH clause which will work in most usual use-cases will be submitted. -- 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] RESET CONNECTION?
Mario Weilguni wrote: Will this patch make it into 8.2? http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php It's a really nice feature, would be extremly useful with tools like pgpool. No, it will not because RESET CONNECTION can mess up interface code that doesn't want the connection reset. We are not sure how to handle that. --- Am Freitag, 7. Juli 2006 19:13 schrieb Bruce Momjian: There are roughly three weeks left until the feature freeze on August 1. If people are working on items, they should be announced before August 1, and the patches submitted by August 1. If the patch is large, it should be discussed now and an intermediate patch posted to the lists soon. FYI, we don't have many major features ready for 8.2. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- 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
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] AIX buildfarm failure
Fixed. --- Tom Lane wrote: Rocco Altier [EMAIL PROTECTED] writes: If I move math.h down after postgres.h in nodeHash.c, the problem goes away. Bruce, you broke it. Have you forgotten the fundamental inclusion rule? postgres.h (or postgres_fe.h, or c.h) first, then system headers, then our own other headers. regards, tom lane -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] monolithic distro (was: Re: Fwd: Three weeks left until feature freeze)
Joshua D. Drake wrote: Aside from obviously the big issue of who maintains all the pgfoundry stuff, I also think that the PostgreSQL family would benefit from a distribution that is more and the kitchen sink style. I do not know exactly if Bizgres could be considered just that? Or maybe it could get promoted to be that? Lukas, that is what www.mammothpostgresql.org is :) Doh, yes .. totaly forgot about that one. Again I think it makes absolute sense to have a nicely sized core for all the friendly forks to base their work on. However I think all newbie PR should be directed at the monolithic distro and not to that nicely sized core. Cluefull people that want to create their own PostgreSQL distro will naturally gravitate to PostgreSQL, while newbies come to PostgreSQL right now. They dont find the feature they are looking for, and we miss out on getting them into PostgreSQL. So what I am suggesting is that PostgreSQL.org should push people towards the monolithic distro. The docs should contain everything that is in the monolithic distro. At conference we should say the name of the monolithic distro etc. Again, the truely cluefull people will naturally gravitate to the PostgreSQL core project while the monolithic distro sucks in the newbies. regards, Lukas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] AIX buildfarm failure
Now it dies on nodeSubplan.c... I am guessing there will be others as well. Perhaps a check to make sure postgres.h is first in the includes can be added to the include checking scripts you have been updating? Thanks, -rocco -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 4:14 PM To: Tom Lane Cc: Rocco Altier; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] AIX buildfarm failure Fixed. -- - Tom Lane wrote: Rocco Altier [EMAIL PROTECTED] writes: If I move math.h down after postgres.h in nodeHash.c, the problem goes away. Bruce, you broke it. Have you forgotten the fundamental inclusion rule? postgres.h (or postgres_fe.h, or c.h) first, then system headers, then our own other headers. regards, tom lane -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] monolithic distro (was: Re: Fwd: Three weeks left
On Thu, 13 Jul 2006, Lukas Smith wrote: Joshua D. Drake wrote: Aside from obviously the big issue of who maintains all the pgfoundry stuff, I also think that the PostgreSQL family would benefit from a distribution that is more and the kitchen sink style. I do not know exactly if Bizgres could be considered just that? Or maybe it could get promoted to be that? Lukas, that is what www.mammothpostgresql.org is :) Doh, yes .. totaly forgot about that one. Again I think it makes absolute sense to have a nicely sized core for all the friendly forks to base their work on. However I think all newbie PR should be directed at the monolithic distro and not to that nicely sized core. Cluefull people that want to create their own PostgreSQL distro will naturally gravitate to PostgreSQL, while newbies come to PostgreSQL right now. They dont find the feature they are looking for, and we miss out on getting them into PostgreSQL. So what I am suggesting is that PostgreSQL.org should push people towards the monolithic distro. The docs should contain everything that is in the monolithic distro. At conference we should say the name of the monolithic distro etc. Again, the truely cluefull people will naturally gravitate to the PostgreSQL core project while the monolithic distro sucks in the newbies. But, that isn't our role ... that should be the role of whomever takes on the role of 'maintainer' for such a monolithic distribution ... its no more our role to decide that pl/Java is better or worse then pl/J ... our role is to provide that core for everyone else to build around ... People like CommandPrompt, Bizgres, EnterpriseDB, Pervasive ... they have the funding to *create* and maintain that, to make sure all the parts they distribute are working properly ... The resources are there, if someone (you?) wants to do this as a FOSS project, but I fear that amount of work (both time and energy) required to make the 'include all, for all' distribution is much much greater then the returns will be ... the more you add in, the more you have to co-ordinate releases with the external projects, and pull/push old/new stuff in as it becomes 'stale', etc ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(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] monolithic distro
Marc G. Fournier wrote: But, that isn't our role ... that should be the role of whomever takes on the role of 'maintainer' for such a monolithic distribution ... its no more our role to decide that pl/Java is better or worse then pl/J ... our role is to provide that core for everyone else to build around ... People like CommandPrompt, Bizgres, EnterpriseDB, Pervasive ... they have the funding to *create* and maintain that, to make sure all the parts they distribute are working properly ... The resources are there, if someone (you?) wants to do this as a FOSS project, but I fear that amount of work (both time and energy) required to make the 'include all, for all' distribution is much much greater then the returns will be ... the more you add in, the more you have to co-ordinate releases with the external projects, and pull/push old/new stuff in as it becomes 'stale', etc ... Yeah, but if PostgreSQL decides to endorse one monolithic distro in the way I described it could give that project hopefully the necessary lift. And the ultimate goal is obviously that some of those newbies coming by way of the monolithic distro turn into people that bring ressources to the PostgreSQL platform/ecosystem. regards, Lukas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] AIX buildfarm failure
Rocco Altier wrote: Now it dies on nodeSubplan.c... I am guessing there will be others as well. I check them all the math.h mentions. --- Perhaps a check to make sure postgres.h is first in the includes can be added to the include checking scripts you have been updating? Thanks, -rocco -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 4:14 PM To: Tom Lane Cc: Rocco Altier; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] AIX buildfarm failure Fixed. -- - Tom Lane wrote: Rocco Altier [EMAIL PROTECTED] writes: If I move math.h down after postgres.h in nodeHash.c, the problem goes away. Bruce, you broke it. Have you forgotten the fundamental inclusion rule? postgres.h (or postgres_fe.h, or c.h) first, then system headers, then our own other headers. regards, tom lane -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
