Re: [HACKERS] Thoughts on maintaining 7.3
I don't believe anyone would work against this, nor could I imagine that anyone would think it was a bad idea, I'm just curious as to how possible it is to do ... For most things probably not that possible. For things like: Simple feature enhancements (preloading of libs) Fixing pl/Language bugs (and making sure they still work on 7.3) Buffer overflow fixes Security problems (the fact that alter user/createuser with encrypted password ' will go into a .psqlhistory file is horrendous) pg_dump/pg_restore enhancements Would entirely be possible. Sincerely, Joshua rake ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com The most reliable support for the most reliable Open Source database. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Thoughts on maintaining 7.3
then maybe they would be willing to donate some small amount each ($500 or so) to pay for backporting issues. Since mostly what I'd want on an older version would be bug / security fixes, that $500 should go a long way towards backporting. Sure. I was under the imporession that 7.4 removed the need to reindex caused by monotonically increasing index keys, no? Someone else brought that up. Maybe I am misunderstanding something but it was my understanding that 7.4 fixes alot of the issues but one of the issues (index bloat) although improved is not entirely fixed and thus we would still need reindex? Tom am I on crack? Yeah, I would rather have had more back porting to 7.2 because there were tons of little improvements form 7.2 to 7.3 I could have used while waiting for 7.4's improved pg_dumpall to come along. Well there ya go :) Sincerely, Joshua Drake Cheers:-) -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Thoughts on maintaining 7.3
and the question as i thought was being discussed (or should be discussed) was what is the level of interest in having this work kept in the community cvs tree vs. someone else's quasi-forked branch... It is my thinking that regardless of commercial backing that the PostgreSQL project as a whole would gain better validity within the commercial world if we maintained releases longer. It is really irrelevant whether somebody pays me or you 500.00 buck to make a patch and submit it to the tree. What is relevant IMHO is that the community is backing a release for longer than 12-18 months. Yes a commercial company could just pick it up and say ... hey we will support it for x (Mammoth 7.3.4 is supported until 2005 for example) but I was more looking at this from an overall community perspective. Sincerely, Joshua D. Drake Robert Treat -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Thoughts on maintaining 7.3
Hello, When I was reading hackers about the fixes you had made, it stated that the index bloat problems should be better. I took that as meaning that although it won't be required nearly as often, we still may need to reindex occassionaly. It was later pointed out to me that this may not be the case, to wit I responded: Tom, am I on crack? Sincerely, Joshua Drake Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: ... having to reindex the database (which 7.4 doesn't fix), It's supposed to fix it. What are you expecting not to be fixed? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Thoughts on maintaining 7.3
Hello, Possible scenario for maintaining 7.3: Only one or two committers using a two stage cvs... one stage for testing (not including sandbox), one stage for commit. Scheduled releases based on non-critical fixes. Quarterly? Of course critical fixes should be released as soon as plausible. Separate mailing list for 7.3 issues, concerns etc... Which would help develop it's own temporary community. Thoughts? Joshua D. Drake Tom Lane wrote: Robert Treat [EMAIL PROTECTED] writes: and the question as i thought was being discussed (or should be discussed) was what is the level of interest in having this work kept in the community cvs tree vs. someone else's quasi-forked branch... I see no reason that the maintenance shouldn't be done in the community CVS archive. The problem is where to find the people who want to do it. Of course we have to trust those people enough to give them write access to the community archive, but if they can't be trusted with that, one wonders who's going to trust their work product either. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Oracle/PostgreSQL incompatibilities
+ CREATE SCHEMA: Sometimes a schema created in PostgreSQL disappears if there is nothing in it. This is more than a bit hard to believe. Can you give an example? We use schema's ALOT in our applications. I have yet to see this happen. + PostgreSQL does not support the NUMBER keyword without (...) i.e. something in parenthesis following it. Don't follow this one either. We don't have NUMBER --- are you speaking of NUMERIC? If so, I'm not aware of any context where you're required to put a precision on NUMERIC. Again, may we see an example? Ditto. Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC Postgresql support, programming, shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL.Org - Editor-N-Chief - http://www.postgresql.org ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Thoughts on maintaining 7.3
Yes, please. Please, please do not force all users to accept new features in stable trees. What if the feature does break compatibility with old features? What if it is truly a new feature? One example would be that we are considering reworking pg_dump/restore a bit to support batch uploads and interactive mode. It would not break compatibility with anything but would greatly enhance one's ability to actually backup and restore large volume sets. Sincerely, Joshua Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC Postgresql support, programming, shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL.Org - Editor-N-Chief - http://www.postgresql.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Thoughts on maintaining 7.3
If we are going to back-patch more aggressively, we _have_ to be sure that those back-patched releases have the same quality as all our other releases. I know that I am probably being semantic here but I in know way want to be more aggressive with back patching. My thoughts for 98% of things in on bugfixes within the existing tree only. Although I am sure for some things we can use (at least as a guide) code being written in 7.4. My whole purpose in bringing the idea up is to increase the adoption rate. My thought isn't to be more agressive per say, but more responsible in our releases. Like I said, I may be, being semantic. Sincerely, Joshua Drake I know people already know this, but it is worth mentioning specifically --- my point is that more agressive backpatching has risks. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: max_connections/shared_buffers (was Re: [HACKERS] Beta4 Tag'd
Anyone see a better way? Switch everything to mmap and pthreads and dump all this antiquated SysV IPC and semaphore junk? *DUCK* You are a brave soult. I salute you. Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC Postgresql support, programming, shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL.Org - Editor-N-Chief - http://www.postgresql.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] CREATE USER bug
Hello, It seems to me that the below should not be able to happen. postgres=# create user with encrypted password '98wq7912a'; CREATE USER postgres=# create user with encrypted password '98wq7912a'; ERROR: CREATE USER: user name with already exists Sincerley, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] BigInt woes
Hello, I believe that the Int8/BigInt items are known issues but I have a knew programmer that ran into it over the weekend (he didn't call me when he encountered the problem, when he should of) and we have a customer that burned some significant time on it as well. Will this be fixed in 7.4? Here is a test case a customer sent me: Suppose you have a table: create table bid ( bid_id bigint not null, bid_time timestamp, constraint bid_pk primary key (bid_id)); Populate it with a million rows or so. This query: explain select bid_id, bid_time from bid where bid_id = 1 Will always sequential scan. This query: explain select bid_id, bid_time from bid where bid_id = '1' Will use the index. Where this really gets to be a pain in the butt is with a UDF in plpgsql... this UDF will only sequential scan: create function bid_check(bigint) returns bool as ' declare in_bid_id alias for $1; begin if (select count(*) from bid where bid_id = in_bid_id) = 1 then return true; else return false; end if; end; ' language 'plpgsql'; The work around is to build the SQL statement in a string, embedding the value of the variable with the quote_literal function and execute it. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC Postgresql support, programming, shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL.Org - Editor-N-Chief - http://www.postgresql.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Thoughts on maintaining 7.3
Hello, O.k. so everyone is basically in agreement of no new features to be backported. How do we implement a stable release maintainer for back releases? I assume we set a scope of of what would go in security/bug fixes only? Sincerely, Joshua Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC Postgresql support, programming, shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL.Org - Editor-N-Chief - http://www.postgresql.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Thoughts on maintaining 7.3
But the kernel goes through this reliable/unreliable cycle --- they would be better off just making the old kernel more and more reliable and focusing on the new kernel for features. The reliable/unreliable cycle will kill your user base. The popularity of Linux would argue that statement a great deal. Sincerely, Joshua Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC Postgresql support, programming, shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL.Org - Editor-N-Chief - http://www.postgresql.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [Fwd: [Python-Dev] HP Test Drive systems]
Hello, I have a solaris machine we could throw up for the community as well if required. Sincerely, Joshua Drake Bruce Momjian wrote: I signed up for an account, and it has already been helpful. I wish I had known about this years ago. I will probably put together a little sourceforge project so I can get access to their Solaris and OS X machines so I will have even better hardware access. Those are the only two OS's missing from the Test Drive site. Thanks for the tip. --- Hannu Krosing wrote: Maybe someone here is also interested ;) Content-Description: Edasi saadetud s?num - [Python-Dev] HP Test Drive systems -- Start of included mail From: Anthony Baxter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Organization: dis- X-formerly-known-as: [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Wed, 01 Oct 2003 15:54:26 +1000 Subject: [Python-Dev] HP Test Drive systems Reply-To: [EMAIL PROTECTED] If you've found the Sourceforge Compile Farm a bit lacking in the numbers of systems available, I highly recommend the HP testdrive program (ok, to be fair, it was originally the DEC testdrive program to allow you to play with OSF/1 on Alphas, then the Compaq testdrive program, but HP's added a bunch of their own systems to it, as well as a wide variety of the free linux and bsd variants). I've appended the list of systems that are currently available to the bottom of this list. mwh and I have been using these to track down all manner of wacky O/S- dependent errors. Sign up for it at http://www.testdrive.compaq.com/ Anthony Test DriveSystem Type HP Tru64 Unix 4.0g(JAVA) AS1200 [EMAIL PROTECTED] (ev56) HP Tru64 Unix 5.1b(JAVA) DS20L [EMAIL PROTECTED](ev68) HP Tru64 Unix 5.1b(JAVA) DS20E [EMAIL PROTECTED] (ev67) HP Tru64 Unix 5.1b(JAVA) ES40 [EMAIL PROTECTED] (ev67) HP Tru64 Unix 5.1b(JAVA) ES45 [EMAIL PROTECTED] (ev68) HP Tru64 Unix 5.1b(JAVA) ES47 2x1GHz (ev7) HP OpenVMS 7.3-2 EFT DS10-L [EMAIL PROTECTED] (ev6) HP OpenVMS 7.3-1 DS20 [EMAIL PROTECTED] (ev6) HP-UX 11i 11.22 rx2600 [EMAIL PROTECTED] (Itanium II) HP-UX 11i 11.22 rx2600 [EMAIL PROTECTED] (Itanium II) HP-UX 11i 11.11 rp2470 [EMAIL PROTECTED] (PA-RISC) HP-UX 11i 11.11 rp2470 [EMAIL PROTECTED] (PA-RISC) Linux Test Drives: Test DriveSystem Type Debian GNU/Linux 3.0 on Intel ProLiant DL360 G2 1.4GHz (P3) Debian GNU/Linux 3.0 on Intel rx2600 [EMAIL PROTECTED] (Itanium II) Debian GNU/Linux 3.0 on Alpha XP1000a [EMAIL PROTECTED] (ev6) Debian GNU/Linux 3.0 on Alpha DS20 [EMAIL PROTECTED] (ev6) Debian GNU/Linux 3.0 on PA-RISC rp5470 [EMAIL PROTECTED] (PA-RISC) Mandrake Linux 9.1 on Intel ProLiant ML530 [EMAIL PROTECTED] (P3) Red Hat Ent Linux ES 2.1 on Intel ProLiant ML530 [EMAIL PROTECTED] (P3) Red Hat Ent Linux AS 2.1 on Intel ProLiant DL360 [EMAIL PROTECTED] (P3) Red Hat Ent Linux AS 2.1 on Intel rx2600 [EMAIL PROTECTED] (ItaniumII) Red Hat Ent Linux AS 2.1 on Intel rx2600 [EMAIL PROTECTED] (ItaniumII) Red Hat Ent Linux AS 2.1 on Intel Intel [EMAIL PROTECTED] (Itanium II) Red Hat Linux 7.2 on AlphaDS20 [EMAIL PROTECTED] (ev6) Red Hat Linux 7.2 on Alpha(JAVA) ES40 [EMAIL PROTECTED] (ev67) Slackware Linux 9.0 on Intel ProLiant ML530 [EMAIL PROTECTED] (P3) SuSE Linux Ent Svr 8.0 on Intel ProLiant DL360 [EMAIL PROTECTED] (P3) SuSE Linux 7.2a on Intel DL590 [EMAIL PROTECTED] (Itanium I) SuSE Linux 7.1 on Alpha DS10-L [EMAIL PROTECTED] (ev6) SuSE Linux 7.1 on Alpha ES40 [EMAIL PROTECTED] (ev67) SuSE Linux 7.1 on Alpha(JAVA) DS20e [EMAIL PROTECTED] (ev67) BSD Test Drives: Test DriveSystem Type FreeBSD 4.8 on Intel ProLiant DL360 [EMAIL PROTECTED] (P3) FreeBSD 4.8 on Alpha XP1000a [EMAIL PROTECTED] (ev6) OpenBSD 3.2 on Intel ProLiant DL360 [EMAIL PROTECTED] (P3) NetBSD 1.6 on Intel ProLiant DL360 [EMAIL PROTECTED] (P3) Cluster Test Drives: Beowulf BrickWall Cluster DS10 DS10-L(8) 466MHz (ev6) HP TruCluster Server 5.1b(JAVA) ES40 883Mhz DS20E 667Mhz OpenVMS 7.3 Galaxy ClusterAS4100 EV56 OpenVMS 7.3 Galaxy ClusterAS4100 EV56 Red Hat Advanced Server Cluster ProLiant DL360x2 [EMAIL PROTECTED] (P3) iPAQ TestDrive Developer Program: Test DriveSystem Type iPAQ iPAQ H3650 Application Test Drives: Test Drive
[HACKERS] Writers Wanted
Hello All: As the new Editor-N-Cheif of PostgreSQL.Org it is my job to make sure that people who want to write about PostgreSQL, can. I will be in constant communication with various publications and will be helping in the advocacy of PostgreSQL through wide spread dissemination http://dictionary.reference.com/search?r=2q=dissemination of the truth ;). I will also be requesting topics from writers from time to time. If you are, or would like to be a writer please contact me at [EMAIL PROTECTED] and include the following information: Name: Email: Experience: Topics you feel qualified to write about: Programming languages known: Willing to work for free: Y/N Lead time needed for average article: 1 week, 1 month etc... I will be in contact with all types of online and print media. Some will not be able to pay a fee but you will still get author credit which can add to your writer validity. Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] *sigh*
Greg Stark wrote: Thomas Zehetbauer [EMAIL PROTECTED] writes: Also will the BUG which causes postgresql to execute a sequential scan when using min()/max()/count() ever be fixed? min()/max() can be rewritten as SELECT $column ORDER BY $column ASC/DESC LIMIT 1 but this should be done by the database, NOT by the user! I would add that this is not a bug as much as a feature request. count() works. It may not be as feature filled as we would like (e.g; it won't use an index) but it does work. Nobody is currently working on this or planning to work on this soon. So no, at least currently it appears this issue will not be changed. Postgresql is open source and this is the hackers mailing list. Feel free to contribute a patch. Personally I think there are greater things that need to be patched versus count(). As you can implement procedures on your own to deliver faster counts. Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open items
Hello, Based on the current open items... when do we expect release? Sincerely, Joshua Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open items
Hello, Well the reason I brought it up was the rather interesting discussion that Jan had today about Vacuum. I was wondering if we were going to explore that before the 7.4 release? Sincerely, Joshua Drake Bruce Momjian wrote: Marc G. Fournier wrote: On Mon, 27 Oct 2003, Joshua D. Drake wrote: Hello, Based on the current open items... when do we expect release? As soon as the items are fixed? :) I am confused why we aren't wrapping up these items. I have waited for the people who proposed these ideas to jump in and do them, but I might start on them myself soon. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.4RC1 planned for Monday
Hello, I know I will probably be flamed into oblivion for this but I would like to make a suggestion about the upcoming release. What if we delayed until the end of the year? The two reasons that I can come up with are: 1. The irritating (but work around capable) bigint index issue. 2. More importantly the recent potential discovery by Jan on vacuum. I have several high end users that are really beating their heads against the wall with even lazy vacuum because of how brutal it can be on the system. If we could make vacuum a little less harsh it could be a large boon. If I am totally off my rocker, so be it but if we were to hit the streets with 7.4 and a vacuum that was 70% (ex) less brutal on the machine it would be a pretty significant statement. Yes all the other fixes are great and cool. Sincerely, Joshua D. Drake Tom Lane wrote: Barring the discovery of any major new bugs, the core committee has agreed to release 7.4RC1 on Monday. Time to get those last-minute fixes in place. I currently have the following issues on my radar screen: Force GRANT/REVOKE by superuser to act as though owner of object? Change libpgtcl to use ByteArray for lo_read/lo_write (ljb's patch) Add option for parallelism limit in make check (Andrew Dunstan's patch) rule/foreign key interaction reported by Michele Bendazzoli plus various minor documentation fixes. Not much there... BTW, 7.4 final will be as early as the following Monday if no problems are detected. We will decide on a week-to-week basis whether we are ready to release final or not. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 7.4RC1 planned for Monday
Sooner or later you have to say this release is done, let's ship it. It's way too late to go back into invention mode for 7.4. I agree with the argument. It is just that the Vacuum one... well is very tempting. On the 7.5 cycle though... I thought 7.5 was basically for win32? Sincerely, Joshua Drake regards, tom lane -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 7.4RC1 planned for Monday
If I understood correctly, Josh was complaining about VACUUM sucking too much of his disk bandwidth. autovacuum wouldn't help that --- in fact would likely make it worse, since a cron-driven vacuum script can at least be scheduled for low-load times of day. autovacuum is likely to kick in at the least convenient times. Exactly! However, we have at this point got only speculative solutions to the too-much-bandwidth problem. If we had something ready to go today, I'd be as willing as the next guy to cram it into 7.4. I'm not willing to go back into development mode for 7.4, though. regards, tom lane -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] AGREGATE FUNCTIONS
Roberto Rezende de Assis wrote: Hello, I would like to know where in the source-code of postgres is located the code of the aggregate functions min, max, avg. I wish to develop more statistical aggregate functions, and I prefer to use C than to write then in the PL/R. http://projects.commandprompt.com/public/pgsql/browser/trunk/pgsql/src/backend/utils/adt http://projects.commandprompt.com/public/pgsql/browser/trunk/pgsql/src/backend/utils/adt/numeric.c http://projects.commandprompt.com/public/pgsql/browser/trunk/pgsql/src/backend/utils/adt That will give you and easy interface to view the code and everything after browser is the CVS source tree so you can look for yourself within your copy of HEAD or 8.1 or whatever. Sincerely, Joshua D. Drake Thanks ___ Navegue com o Yahoo! Acesso Grátis, assista aos jogos do Brasil na Copa e ganhe prêmios de hora em hora! http://br.yahoo.com/artilheirodacopa/ ---(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 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] How to avoid transaction ID wrap
Mark Woodward wrote: On Wed, Jun 07, 2006 at 07:07:55PM -0400, Mark Woodward wrote: I guess what I am saying is that PostgreSQL isn't smooth, between checkpoints and vacuum, it is near impossible to make a product that performs consistently under high load. Have you tuned the bgwriter and all the vacuum_cost stuff? I've get to find a case where I couldn't smooth out the IO load so that it wasn't an issue. In several project that I have been involved with, PostgreSQL had most of the important features to be used, but in one project, checkpoints caused us to time out under load. In this current project I am researching, I know that vacuum may be an issue. The load is brutally constant. I was recently involved in a project where we had to decrease the checkpoint_timeout . The problem was, that the database was performing so many transactions that if we waiting for 5 minutes, checkpoint would take entirely too long. We ended up doing checkpoints every two minutes which with the increase in checkpoint_segments and adjustment of bgwriter settings would level out the load. Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- === 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] How to avoid transaction ID wrap
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: I was recently involved in a project where we had to decrease the checkpoint_timeout . The problem was, that the database was performing so many transactions that if we waiting for 5 minutes, checkpoint would take entirely too long. Seems like the correct fix for that is to make the bgwriter more aggressive. Narrowing the checkpoint spacing is a pretty horrid answer because of the resulting increase in full-page-image WAL traffic. Well we did that as well. Here are the basic symptons: During normal processing which contained about 250 connections everything was fine. A checkpoint would start and connections would start piling up, sometimes breaking 1000. We narrowed that down to users having to wait longer for query execution so instead of just reusing connections new connections had to be initiated because the existing connections were busy. We tried many different parameters, and bgwriter did significantly help but the only solution was to make checkpoints happen at a much more aggressive time frame. Modify bgwriters settings and the checkpoint actually increased our velocity by about 70% by the time we were done. Bgwriter was definitely the largest chunk of that although other parameters combined outweighed it (effective_cache, shared_buffers etc...). Sincerely, Joshua D. Drake 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 -- === 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 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] TODO: Rename some /contrib modules from pg* to pg_*
Hello, I read this as: 1. Fix makefiles so that contrib modules such as pgcrypto are not pg_crypto 2. Move directories to reflect above 3. Fix source and makefiles within sub project directories to create binaries and libs with correct output.. thus libpgcrypto.so.0.0 would become libpg_crypto.so.0.0 Is this correct? If so I personally would like to claim this TODO. 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 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] TODO: Rename some /contrib modules from pg* to pg_*
Joshua D. Drake wrote: Hello, I read this as: 1. Fix makefiles so that contrib modules such as pgcrypto are not pg_crypto err are now 2. Move directories to reflect above 3. Fix source and makefiles within sub project directories to create binaries and libs with correct output.. thus libpgcrypto.so.0.0 would become libpg_crypto.so.0.0 Is this correct? If so I personally would like to claim this TODO. 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] TODO: Rename some /contrib modules from pg* to pg_*
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: 1. Fix makefiles so that contrib modules such as pgcrypto are not pg_crypto 2. Move directories to reflect above 3. Fix source and makefiles within sub project directories to create binaries and libs with correct output.. thus libpgcrypto.so.0.0 would become libpg_crypto.so.0.0 That will lose the CVS history of the modules, which is not worth the small benefit gained from more consistent-looking names. Renaming existing shared libraries is also a very bad idea, because it will break existing dump scripts. I don't know when that TODO item got put in, but it's a stupid idea. O.k. just trying to help :) Joshua D. Drake regards, tom lane -- === 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 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] TODO: Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
Doesn't this exist in: src/tools/fsync? Do we just need to make it more user friendly? 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 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] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(), pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef()
Hello, I can guess some of these: pg_get_tabledef() : Would take a table name and return the columns and associated types pg_get_acldef(): Would take an object name and return the associated roles and permissions for the object pg_get_typedefault(): This one I am unsure about pg_get_attrdef(): This one I am unsure about pg_get_domaindef(): Would take the name of a domain constraint and return the definition pg_get_functionef(): Would take the name of a function and return its soure. However, a function can have the same name with different arguments, so I am a little unsure. So could I get some further definition? Joshua D. Drake ---(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] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: So could I get some further definition? There are two fairly strong reasons for NOT trying to push more logic into the backend from pg_dump: 1. It would remove the freedom we currently have to make pg_dump adapt dumps from old servers to match newer syntax/semantics. This has saved our bacon more than once in the past, so it shouldn't be given up lightly. 2. The backend functions invariably read the catalogs under SnapshotNow rules, making pg_dump unable to promise a consistent snapshot to the extent that it relies on them. O.k. color me stupid but what does what you said above have in any way to do with what the requirements for these functions are? Maybe I am misunderstanding the TODO (which is entirely possible due to the complete lack of documentation on the feature) but I *thought* all I was going to do was create 6 functions that could be called to get various useful information? For example, pg_get_tabledef() would be a very handy function to use for just about any abstracted API. As it stands now most (like Pear) create their own custom queries/functions to handle it but they are more often then not very innefficient. ? Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- === 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] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
Maybe I am misunderstanding the TODO (which is entirely possible due to the complete lack of documentation on the feature) but I *thought* all I was going to do was create 6 functions that could be called to get various useful information? For example, pg_get_tabledef() would be a very handy function to use for just about any abstracted API. As it stands now most (like Pear) create their own custom queries/functions to handle it but they are more often then not very innefficient. I thought the TODO item was exactly what you described: * %Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(), pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef() We have per-server-version checks in pg_dump, so I figured the idea was to use more of those functions if the exist, like we do now. It is true that you can't modify them for old versions as easily as you can if they are hardcoded in pg_dump, but we our existing functions seems to work fine. O.k. so now what I am getting from this thread is, the functions exist now in pg_dump but we want to pull them out of pg_dump and push them into the backend? 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] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: O.k. so now what I am getting from this thread is, the functions exist now in pg_dump but we want to pull them out of pg_dump and push them into the backend? That's exactly what I *don't* want to do. If you can think of a use-case for these functions outside of pg_dump, feel free to put them in the backend, but pg_dump should continue to do things as it does now. O.k. well my thought was just to implement the functions for the backend. I wasn't even aware of the pg_dump dependency. They would be very useful for application developers in general. So how about this. I can implement them and submit them for hopeful inclusion and I will let hackers argue about whether or not they need to also be in pg_dump ;). If we can go down this route, can we go back to my original post so that I insure that I develop something that you guys want? Secondly, is this something that I can do with SQL and SETOF or do you want them in C? *** I can guess some of these: pg_get_tabledef() : Would take a table name and return the columns and associated types pg_get_acldef(): Would take an object name and return the associated roles and permissions for the object pg_get_typedefault(): This one I am unsure about pg_get_attrdef(): This one I am unsure about pg_get_domaindef(): Would take the name of a domain constraint and return the definition pg_get_functionef(): Would take the name of a function and return its soure. However, a function can have the same name with different arguments, so I am a little unsure? So could I get some further definition? *** 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 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] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
Well, the argument against changing pg_dump is that it would impact the ability to use the newer version of pg_dump with older backends (which would be lacking these functions). ISTM what would be best is to add the functions to the backend, and add a TODO or comments to pg_dump indicating that it should be changed to use these functions once 8.1 is no longer supported. Or you could make pg_dump's use of this code dependent on the server version it connected to. Off list I was speaking with AndrewD and he said that he would expect that if we called pg_get_tabledef() it should return the CREATE statement for the table. With all due respect to Andrew, why? At least in my mind these functions really belong to app developers.. e.g; CREATE TABLE foo (id serial); SELECT pg_get_tabledef(foo) would return id, serial Not: CREATE TABLE foo (id serial); I mean, I can do either but I would like to get a clear definition of what we are looking for here. Maybe: pg_get_tabledef is the actual SQL and pg_get_tabledesc() is the column, datatype output? I guess I don't see the advantage of putting pg_dump -s -t in the backend. 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 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] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
Well, I certainly don't think a setof name, type is adequate for
pg_get_tabledef(). What about constraints? And what you are suggesting
can probably be got by very simple queries against either the catalog or
the information schema, and seems to me to have little value.
Well it isn't simple queries because they aren't documented. It is a lot
easier to say, select pg_get_tabledesc('foo') then a select with 3
different joins and a couple of where clauses (I actually don't think it
is that bad. I have a query that does it.) What I am suggesting is that
we have a standard way for APIs to get information that they need.
The information doesn't need to be limited to just the name and type, we
could add cosntraint info. I am not against that at all.
Anyway, I suggest having both functions. One that will spit out the
actual create information, and the other set that gives user space
usable information.
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] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
CREATE TABLE foo (id serial); I mean, I can do either but I would like to get a clear definition of what we are looking for here. Maybe: pg_get_tabledef is the actual SQL and pg_get_tabledesc() is the column, datatype output? I guess I don't see the advantage of putting pg_dump -s -t in the backend. If all you want is column, datatype, why not just use info_schema, or newsysviews? Or even the base catalogs? Where do I look in the info_schema? How do I know exactly what I need? What is newsysviews? Of course I know the answers to these but many people don't. Newsysviews is a no-op unless it is in the backend (will it be for 8.2?). Secondly in a email I just sent I did say we can add anything we want, but the CREATE TABLE statement doesn't seem that useful. I will create either or both I don't really care :). ISTM what would be of the most value is a way to get the actual DDL you need to create the table (which includes a heck of a lot more than just column names and data types). Name and datatype was just an example. I am trying to get people to actually provide feedback (thank you). Andrew brought up that also including the constraints would be a good idea which I agree. 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] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: If all you want is column, datatype, why not just use info_schema, or newsysviews? Or even the base catalogs? Where do I look in the info_schema? How do I know exactly what I need? What is newsysviews? Exactly the same arguments can be made against any new functions we invent. OTOH, I do not think these arguments apply to selecting from information_schema; that is SQL standard, and if someone doesn't know what to do with it I don't think it's our fault. I am not blaming us :). I am just saying that certain functions can make life easier. What is easier? test=# select column_name, data_type from columns where table_schema != 'pg_catalog' and table_name = 'email'; column_name | data_type -+--- score | real Or: select pg_get_user_tabledesc(email); This is the basis of my argument. I don't really have anything to add. :) Joshua D. Drake regards, tom lane -- === 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] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
Alvaro Herrera wrote: Joshua D. Drake wrote: Name and datatype was just an example. I am trying to get people to actually provide feedback (thank you). Andrew brought up that also including the constraints would be a good idea which I agree. You also need rules, triggers, inheritance, indexes, primary key specification, foreign keys, default values, CHECK constraints, storage configuration (i.e., plain, extended, etc), statistics configuration. Maybe I'm still missing something. How do you do all that with a single result set? My argument is to find a way to make it a little easier for application and API developers. Most of those people will not need the storage configuration or the statistics. Nor will they likely (although less powerful of an argument) need the foreign key information. Default values? Maybe. Check constraints o.k. It is certainly possible to build a function to return all of this in a result set. 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 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] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
Hello, Trying to get back on point. What is the scope of work for the TODO item? Forget everything else I brought up. What is the goal of the existing TODO? Is it to return the CREATE statements for each (where applicable)? Is it just to create backend versions of the the identical functions in pg_dump? 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 5: don't forget to increase your free space map settings
Re: [HACKERS] TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Trying to get back on point. What is the scope of work for the TODO item? Forget everything else I brought up. What is the goal of the existing TODO? I'm not sure that the TODO item has a reason to live at all, but surely the first item of work for it should be to figure out what its use-case is. If pg_dump isn't going to use these functions, what will? Well I can't think of a reason to use the functions as a way to deliver CREATE statements. Anyone else have thoughts? Joshua D. Drake regards, tom lane -- === 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] TODO: Add pg_get_acldef(), pg_get_typedefault(),
Before we pull pg_dump to bits let's identify some actual benefit from doing so. If you look at the code you will see that it is more than somewhat complex. A large scale move like you are proposing would be very high risk, IMNSHO. From a person who deals with customer migrations daily perspective. Anything that is going to put the stability and integrity of pg_dump/pg_restore in *any* way, is a no op. 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] CSV mode option for pg_dump
Andrew Dunstan wrote: Something someone said on IRC just now triggered a little memory ... I think we should provide an option to have pg_dump work in CSV mode rather than text mode. This probably doesn't have much importance in the case of text dumps, but in custom or tar dumps where you might want to get at individual data members, having an option for CSVs that you want to load into some other product might be nice. This should be a pretty low cost item, I expect (good newbie project?) Uhh... just about any application that can import CSV can import our dumps. It just tell it the delimiter is a tab. Joshua D. Drake thoughts? 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 6: explain analyze is your friend
Re: [HACKERS] CSV mode option for pg_dump
No it won't, not if there are tabs in the data. snipping noise Hmmm then would just double quoting the data work? At least in OOCalc (and IIRC Excel) there is the ability to select a text delimiter. 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] CSV mode option for pg_dump
Bill Bartlett wrote: Here's me speaking up -- I'd definitely use it! As a quick way to pull data into Excel to do basic reports or analysis, a CSV format would be great. Why not just use ODBC? 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] CSV mode option for pg_dump
Bruce Momjian wrote: Good point. The number of CSV options would be hard to support for pg_dump. Any thoughts from anyone on how to do that cleanly? Could we just support the default behavior? Although I don't see a real need for the feature, I do think that if we were to support 1 (well two if you include the already tab delimited) csv output it would be a large amount of bloat. Perhaps we could pick 1 output, say comma delimted with quoted fields? foo,bar ,baz Joshua D. Drake --- Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I wish I could understand why people are so keen to make other people turn handsprings in order to avoid a feature which, as Bruce points out, is already on the TODO list, and which, by my 10 minute analysis, would involve almost trivial code impact and risk. If this involved major impact I might understand, but it really doesn't. Supporting all of the CSV options in pg_dump would involve major bloat in its option set, and it already has far too many options. If it were just a matter of adding a --csv switch I wouldn't be complaining, but there are half a dozen more sub-options, and it seems like every time we turn around someone is finding a reason for another one. Propagating all that cruft through pg_dump would be a PITA, and updating it to track future additions would be too. Furthermore, the entire rationale for the feature is predicated on the claim that programs other than pg_restore might find it useful. But this conveniently ignores the fact that if there are any such programs in existence, what this will really do is BREAK them, because they won't be able to cope with all the variants that pass for CSV. My opinions would be less negative if I thought that CSV were a well-defined format that would never change. I don't believe that it has either property, however, and so I'm against letting it get into our dump file format. I think we'll just live to regret it if we do. 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 -- === 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] CSV mode option for pg_dump
Rod Taylor wrote: On Mon, 2006-06-12 at 16:28 -0400, Bill Bartlett wrote: Can't -- the main production database is over at a CoLo site with access only available via SSH, and tightly-restricted SSH at that. Generally one of the developers will SSH over to the server, pull out whatever data is needed into a text file via psql or pg_dump, scp the file(s) back here and send them to the user. I don't get it. If you can use psql then you already have csv support. psql -c 'COPY pg_class TO STDOUT WITH CSV' postgres pg_class.csv If you data looks like this: foo barbaz bing You are o.k. You have three columns, tab delimited. However if you data looks like this: foo bar baz bing You have a problem. foo is one column bar and baz are a single column bing is a single column How does excel know that bar baz is a single column? It doesn't because you told it to delimit on tabs and thus you have four columns as far as Excel is concerned. An alternative although I don't know what kind of headaches it would cause is to have a text delimiter as well as a field delimter, e.g; foo bar baz bing Sincerely, Joshua D. Drake -Original Message- From: Joshua D. Drake [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 4:15 PM To: Bill Bartlett Cc: 'Andrew Dunstan'; 'Tom Lane'; 'PG Hackers' Subject: Re: [HACKERS] CSV mode option for pg_dump Bill Bartlett wrote: Here's me speaking up -- I'd definitely use it! As a quick way to pull data into Excel to do basic reports or analysis, a CSV format would be great. Why not just use ODBC? 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 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] CSV mode option for pg_dump
Would that be adequate, or do we really want to reimplement and maintain all the output format complexity in our own code, in C? I think the point is that we should provide a native implementation because not everyone is crazy enough to use perl (blatant jab ;)). I would never expect a customer to write a perl or python script just to get their data in what is widely considered a standard business format that can be imported by their userland application. The people on the hackers list, are NOT the target for this feature. The people on general, admin and novice are. Sincerely, Joshua D. Drake Cheers, Steve ---(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 5: don't forget to increase your free space map settings
Re: [HACKERS] UPDATE crash in HEAD and 8.1
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: update pk set id = max(id) + 2; I'm fairly sure this query is illegal per spec. There are ancient discussions in the archives about whether aggregates in an UPDATE target list can have a consistent interpretation or not. We never found one, but never got around to disallowing it either. Maybe it's time. If you try it with something like sum() you don't get a crash, but you do get rather bizarre behavior. On 8.x (7.4 and 7.3 as well) it will update 1 row :). On 8.1 and HEAD it crashes. This has been verified on 32bit, 64bit x86 and PPC. Having said that, this may well expose a bug in the MAX-optimization code that has consequences for more useful queries. I'll take a look later today if no one beats me to it. Sincerely, Joshua D. Drake regards, tom lane ---(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 5: don't forget to increase your free space map settings
Re: [HACKERS] buildfarm stats
On Tuesday 04 July 2006 22:14, Chris Mair wrote: Thanks for the stats Andrew. Out of interest, can you easily tabulate the number of failures against OS? Or, more generally, even put a dump of the DB (without personal infos of course :) somewhere? Bye, Chris. PS: and don't say you're running it in MySQL ;) Well as the host, I guarantee you that it is NOT running mySQL :) Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(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] update/insert,
Which is faster will probably depends on what is more common in your DB: row already exists or not. If you know that 99% of the time the row will exist, the update will probably be faster because you'll only execute one query 99% of the time. OK, but the point of the question is that constantly updating a single row steadily degrades performance, would delete/insery also do the same? Yes. Delete still creates a dead row. There are programatic ways around this but keeping a delete table that can be truncated at intervals. Joshua D. Drake ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] lastval exposes information that currval does not
I am well aware of what security definer means. The significant part of
this example is that lastval() will allow the caller to see the value of
a sequence where currval('seq') will not. This means that things which
might have been forbidden in 8.0 are now accessible in 8.1.
It also means that revoking usage on a schema is not sufficient to
prevent a user from accessing things within that schema, a property that
makes me quite uncomfortable.
Then the public schema must drive you nuts :). If you were to create the
function as a non-super user you would probably be good.
Joshua D. Drake
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [GENERAL] UUID's as primary keys
On Saturday 08 July 2006 14:54, Jim Nasby wrote: On Jul 6, 2006, at 4:02 PM, Thomas Hallgren wrote: In answer to your question, though my opinion carries no special weight at all, I would suggest adding a bare bones 16-byte data type to core and a second binary-compatible data type based on it that parsed/output as uuids. The extended uuid libraries should only go in pgfoundry/contrib. I second that. +1. If there's enough user demand we can look at adding the type to core (I don't see any real advantage to contrib over pgFoundry for this). The advantage of contrib over pgFoundry is that it will be packaged by the major distributions. Every distribution includes a package of the contrib modules. 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 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] pgsql-patches considered harmful
On Sunday 09 July 2006 20:00, Greg Stark wrote: Pursuant to a conversation this evening I would like to a suggestion: BIRT pgsql-patches should be abolished in favour of something else that accomplishes the bandwidth-reduction aspect without the downsides. Alternatively, people could just use patches for patch submission and keep all discussion on hackers. 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] Removing AddDepends; should I bother with a project?
On Monday 10 July 2006 11:43, Gavin Sherry wrote: On Mon, 10 Jul 2006, Bruce Momjian wrote: Josh Berkus wrote: Folks, For the code sprint, I'm starting off by removing the projects from contrib which need to be removed by still have some usefulness. I'm not exactly sure what to do with adddepends, though. It seems unlike to lead an independent existence on pgFoundry; I'm inclined to just nuke it. I vote for the nuclear option. ;-) There are still 7.2 systems out there which need it. My understanding is that 7.2 is EOL... if people have 7.2 and need it they can pull the sources from anythin = 8.2 yes? So I vote nuke! Joshua D. Drake The problem is, adddepend is broken when run against 8.1. It breaks on serial, I think. Gavin ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- === 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
On Tuesday 11 July 2006 13:49, Andrew Dunstan wrote: Joshua D. Drake wrote: ... and before you say it, No. I do not wear a tie. Maybe you need to ... ;-) /me bows before the gods who thoust commit. cheers andrew -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL 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 Tuesday 11 July 2006 09:59, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Thomas Hallgren wrote: 5. I'll need committer rights to the PL/Java part in order to maintain it. Does our CVS setup cater for seggregated rights like this? Or would that be done on a trust basis? No, and yes. However, I don't have a problem with giving Thomas committer access --- I'm just dubious about having PL/Java in the core distro at all. Personally I would like to see in core, but it is not from a technical perspective. It is purely from a marketing perspective (doubt that carries much weight here ;)). Having pl/Java helps PostgreSQL in the minds of all those tie wearing decision making freaks... and before you say it, No. I do not wear a tie. Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [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 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] More nuclear options
Given the current number of projects that have no code / files / anything associated with them on pgfoundry/gborg right now, this argument rings a little hollow. I would say that: Given the current number of projects that have no code / files / anything associated with them on pgfoundry/gborg right now, this argument rings a little hollow. Strengthens JoshB's argument, not lessens it. That is also an argument for Gforge admins, not hackers :) In a year nobody has spoken up for those specific projects. Who's going to maintain them? Who's going to use them? People do get pointed at adddepends even today... certainly no one will do anything with these projects if you nuke them, but I like giving people options... your call though. They will always be able to pull down the source from a previous release. 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] More nuclear options
Again, it's the same question. If *you* want to be the maintainer, I'll put it on pgfoundry. Otherwise, you're asking me to be responsible for the code because you don't want to throw it away. Josh, How about a general call for maintainers? Post it to general, hackers and advocacy (maybe even the front of PgFoundry and or PostgreSQL.Org?) that asks if anyone would like to take over maintainership of the handful? Have a closing date for it, e.g; leave it open for a week and then if no one steps up --- its over and we nuke them with prejudice. Sincerely, Joshua D. Drake --Josh Berkus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL 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
I'm afraid there's not much in the PL/Java type system that could be generalized and shared. Perhaps if we had other languages with very similar capabilities (like C# for instance) but even then I have some doubts. The good news in my opinion is that if PL/Java would make it to the core it could make a good reference implementation for other equally advanced language mappings. What is the actual concern with having PL/Java in core, versus say PL/Perl? Sincerely, Joshua D. Drake Regards, Thomas Hallgren ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
On Wednesday 12 July 2006 04:15, Dave Cramer wrote: Absolutely PL/J should be considered in the same light as PL/Java. Consider this a request for PL/J to be included in the core. Frankly I don't care which one is used, as long as the one (and ONLY one) that is included is the most mature and stable. Sincerely, Joshua D. Drake Dave On 11-Jul-06, at 12:50 PM, Josh Berkus wrote: David, It's good to integrate things with the core as needed. What plans do we have to integrate PL/J? None, if the PL/J team doesn't speak up. So far I have yet to see a request for PL/J or even a release notice. --Josh ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 6: explain analyze is your friend -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL 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
I concur with this. The needs for a module like PL/Java is very different then the needs of PL/Perl so let's get some more PL's in before we do a refactoring effort to create common API's. Personally, I'm not sure what would be included. The call handler API's together with the SPI API's are in essence what you need. The rest is fairly specialized anyway. Well I know it isn't an API per say, but one interesting tid bit as an example is that PLphp does not need the PostgreSQL source to compile. It only needs pgxs and the relevant headers etc... Perhaps that is one way to go... All PLs use pgxs? As the project grows for various reasons, the number of hackers in the community will grow as well. PL/Java for instance, does not come without resources :-) We have already grown for hackers quite a bit this year as they mature I think we will see even more patch review eyes and such... Soon. Sincerely, Joshua D. Drake Regards, Thomas Hallgren ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
Thomas Hallgren wrote: Tom Lane wrote: ... equal claim to inclusion in core. Perhaps more, because it gives us an extra layer of insulation from JVM licensing questions. Tom, Why to you persist talking about licensing issues with PL/Java? There are none. PL/Java builds and runs just fine with gcj and the above statement is completely false. Just to further this with actual documentation :) 1.1 What license is used for libgcj? libgcj is distributed under the GPL, with the 'libgcc exception'. This means that linking with libgcj does not by itself cause your program to fall under the GPL. See LIBGCJ_LICENSE in the source tree for more details. Sincerely, Joshua D. Drake Dave, What JVM requirements does PL/J currently have? What license implications are imposed by the components that it depends upon? Regards, Thomas Hallgren -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL 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
Thomas Hallgren wrote: Tom Lane wrote: Thomas Hallgren [EMAIL PROTECTED] writes: Why to you persist talking about licensing issues with PL/Java? There are none. PL/Java builds and runs just fine with gcj and the above statement is completely false. Um ... if you use it with gcj, there may or may not be any licensing problems (please recall we are trying to be a BSD-only project, not a BSD-and-LGPL project), You have no problems using gcc, gnu-make, etc. What's the difference? Well there is a couple of literal differences. gcc, gnu-make are irrelevant. What is relevant is libc which is LGPL. Gcj IS GPL, not LGPL :( it just has an exception clause Keep in mind that that there are all kinds of oddities when mixing licenses. Is Sun's JVM GPL compatible? If not, the plJava can't use it. What happens when the FSF inevitably removes the license clause and makes it pure GPL? Now all of this being said, I doubt there is actually an issue here because: It doesn't HAVE TO BE BUILT, it is not a derivative product. It doesn't ship with the JVM which means it is up to the user to break the license not the PostgreSQL project... However that last one is bad mojo :( Sincerely, Joshua D. Drake but what of people who use some other JVM? It's not like gcj works for everyone yet. What of them? If they decide to use another JVM, well, then let them. I don't see where that becomes a licensing problem from PostgreSQL. Regards, Thomas Hallgren -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL 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
Well, assume that FSF indeed did remove the exception. It would take me 30 minutes or so to create a substitute BSD licensed dummy JNI library with associated headers that would allow PL/Java to be built without any external modules at all. It's then completely up to the user what he/she wants to slot in as a replacement. Do we want to do that? I mean (and I am not saying it is, I am asking) is that a bit grey? I would prefer it be black and white. Are their JVMs that are BSD compatible? It is my understanding that you can ship Java (I could be completely on crack here) in a closed source product without issue right? If so... then wouldn't our argument be to strongly suggest that they use the Sun JVM (or IBM if that is relevant?). Sincerely, Joshua D. Drake Regards, Thomas Hallgren -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL 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
Thomas Hallgren wrote: Joshua D. Drake wrote: What happens when the FSF inevitably removes the license clause and makes it pure GPL? I'm sorry but I don't follow. You're saying that it's inevitable that FSF will remove the 'libgcc' exception from libgcj? Why on earth would they do that? My guess is that it will go the other way (i.e. LGPL). What's the logic in having different licenses on libg++ and libgcj? You are trying to apply logic to what is a political organization. Keep in mind that LGPL stands for LESSOR GPL. RMS would prefer that ALL licenses be under the GPL (or something very similar) that does not allow anyone to close source the software. This isn't really the point of the thread though. Sincerely, Joshua D. Drake Now all of this being said, I doubt there is actually an issue here because: It doesn't HAVE TO BE BUILT, it is not a derivative product. Well, assume that FSF indeed did remove the exception. It would take me 30 minutes or so to create a substitute BSD licensed dummy JNI library with associated headers that would allow PL/Java to be built without any external modules at all. It's then completely up to the user what he/she wants to slot in as a replacement. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 6: explain analyze is your friend -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
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
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
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
[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
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
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] 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] monolithic distro
Yeah, but if PostgreSQL decides to endorse one monolithic distro in the way I described it could give that project hopefully the necessary lift. And the ultimate goal is obviously that some of those newbies coming by way of the monolithic distro turn into people that bring ressources to the PostgreSQL platform/ecosystem. Should Linus endorse (or does he?) one distro of Linux, or should they not live on their own merits? No he does not. I believe leaving the expert opinions to the experts is a good argument. I also believe that anyone on this list has a right to express their opinion and make it known. However, as a group of which I am a part of, I do not believe we (PostgreSQL.Org) should be endorsing anything but the core project. I for example, will endorse PL/Java. Not because of anything to do with Dave but because of the research I have done to date, PL/Java is more mature. I also currently endorse Slony-I for 8.1 installations but that is only because we don't have a 8.1 release yet (4 weeks W00t!). I on the other hand, do not endorse Perl or anything to do with Perl :) Sincerely, Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [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 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
Hey JD, I notice that we don't have a port for plphp either ... if one of your guys wants to create one, I can get it committed ... DarcyB is supposed to be handling that :) Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Fwd: Three weeks left until feature freeze
Peter Eisentraut wrote: Joshua D. Drake wrote: Were trying man :) I have people building for most major distributions at this point. We should have FreeBSD soon, as well as MacOSX. How is this different (or better) than what is already in FreeBSD ports? There is no functional difference. It is a business difference. It is supported. It is also the idea that we will provide newer postgresql releases for all the support platforms. Like how we provide RPMS even for older version of Fedora. Most people who run FreeBSD have no need for Mammoth, until possibly they want to upgrade via ports to a new version of PostgreSQL but they don't want to upgrade FreeBSD. Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 6: explain analyze is your friend -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL 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
I believe it was Lukas who mentioned elsewhere, this is not a vendor nuetral project. I actually am already working on a adding a list of os/package options to the download page based on other feedback, are people comfortable allowing mammothpostgresql to go on that list? (I wouldn't be mainly because I don't see a clear distinction between it and things like mammoth replicator) The distinction is that mammoth postgresql doesn't have replication :). It is fairly clear on the website. All the links on the CMD website take you directly to www.mammothpostgresql.org which very clearly states: Mammoth PostgreSQL is a business and developer complete PostgreSQL Distribution. Based on PostgreSQL 8.1.4, Mammoth PostgreSQL is designed to provide all the software you need to use PostgreSQL in your environment. The distribution is 100% F/OSS sofware with the exclusion of Mammoth Replicator which can be purchased separately. -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Fwd: Three weeks left until feature freeze
Marc G. Fournier wrote: On Thu, 13 Jul 2006, Joshua D. Drake wrote: Most people who run FreeBSD have no need for Mammoth, until possibly they want to upgrade via ports to a new version of PostgreSQL but they don't want to upgrade FreeBSD. 'k, up to now, you had me ... but what does upgrading to a new version of PostgreSQL have to do with upgrading FreeBSD? They are totally different sub-systems ... I am not exactly sure how it works in FreeBSD but I can speak from Fedora and Ubuntu. For example there is NOT an PostgreSQL 8.1 for Ubuntu Breezy. We want to continue to provide for older distributions (without breaking package compatibility). Sincerely, Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [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] Fwd: Three weeks left until feature freeze
I believe it was Lukas who mentioned elsewhere, this is not a vendor nuetral project. I actually am already working on a adding a list of os/package options to the download page based on other feedback, are people comfortable allowing mammothpostgresql to go on that list? (I wouldn't be mainly because I don't see a clear distinction between it and things like mammoth replicator) I have no problems with it ... there is no license or cost to use, and, I'm guessing from what Joshua has said, the source code come with it ... Yep, direct access :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [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] Fwd: Three weeks left until feature freeze
Peter Eisentraut wrote: Joshua D. Drake wrote: For example there is NOT an PostgreSQL 8.1 for Ubuntu Breezy. http://packages.ubuntu.com/breezy-backports/misc/ Thanks Peter :), I knew about backports but didn't know what was in there. But what about when 8.2 comes out? Doubtful that they will release for breezy because a new version of Ubuntu will be out by then. Example, Hoary doesn't have 8.1 available :) Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL 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] monolithic distro
Since I appreantly like monologs .. MySQL also has other features that are not available via pgfoundery like being able to determine the default charset on the database, table and column level, as well as COLLATE support to determine the sort order at runtime. SHOW ALL; ? Anyways what I want to make clear is simply that there are plenty of features that come with the default distro of other RDBMS that are only available via the pgfoundery. There are also plenty of features available in pgfoundry not available in any other RDBMS. However newbies that evaluate which RDBMS to use will probably never know. regards, Lukas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] contrib promotion?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: There has been action to clean up and remove some contrib modules, and this is good. I would like to suggest that we should try to move one or two the other way, namely right into the core proper, on the ground that they have widespread applicability and should have maximum visibility. I'm talking particularly about pgcrypto and tsearch2, and the main thing lacking that I see with these is documentation. I don't see a strong need for moving pgcrypto into core, and there's at least one argument against it: if someone needs a crypto-free version of postgres for use someplace with benighted laws, they would be screwed. Doesn't our inclusion of md5() pretty much blow that argument away? (Just asking). 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 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] Online index builds
That said I'm not sure how much I can do here. For a substantial index we should expect most of the time will be spent in the tuplesort. It's hard to see how to get any sort of progress indicator out of there and as long as we can't it's hard to see the point of getting one during the heap scan or any of the other i/o operations. Well from a DBA perspective, just knowing that something productive is happening is useful. When using vacuum I almost always use vacuum verbose, just so I have an idea of what is going on. 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] Windows buildfarm support, or lack of it
Kris Jurka wrote: On Sun, 16 Jul 2006, Tom Lane wrote: [windows buildfarm machines run irregularly] For my part the difficulty is scheduling. As a primarily unix user I understand cron, but have no idea what the windows equivalent is. For my cygwin buildfarm member I setup cron, but the make step failed for every build for unknown reasons while succeeding if not run from cron. That further demotivated me from scheduling mingw builds. Perhaps snake's maintainer could share his configuration? There is job schedulers for Windows. I have no idea how good or bad they are. Joshua D. Drake Kris Jurka ---(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 5: don't forget to increase your free space map settings
[HACKERS] plPHP and plRuby
Hello, We were going to submit plPHP to core for inclusion but it is not ready yet. Namely it requires the apache SAPI which could introduce some portability issues. The other issues it has (such as some array parsing problems) are minor and could probably be fixed easily within the beta period but the SAPI is a show stopper. As some of you know, we have also procured permission to relicense plRuby so that the project can include it in core. I have a version that works with -HEAD. However plRuby is even a stranger beast as it uses an entirely ruby build system. I am also fairly confident that it does not meat the PostgreSQL style guidelines. Is there enough interest in plRuby to get it where it needs to be for possible inclusion into 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 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] SPI Elections and mailing list
Agent M wrote: Sorry- perhaps I misunderstand the purpose of your group, but how can you claim to be making decisions on software in the public interest on a private, paid-member mailing list? Well it isn't paid-member mailing (I don't think) but you do need to be a contributing member (ahh that is where it comes from). When they say contributing, they are talking about people who are recognized within the FOSS community for their contributions. The SPI is a non-profit that is designed to help support other FOSS projects. In our case PostgreSQL. The PostgreSQL Fundraising Group (of which I am apart) is using the SPI non-profit status to allow for tax deductible donations to the PostgreSQL project. Sincerely, Joshua D. Drake -M On Jul 16, 2006, at 2:10 PM, Josh Berkus wrote: Folks, Hopefully by now a bunch of you have joined as Software in the Public Interest Contributing members per my earlier e-mail and are aware that the SPI annual board election has started. If you are a registered contributing member with SPI, elections are at: http://members.spi-inc.org/vote/ and candidate statements are at: http://www.spi-inc.org/secretary/votes/vote5/ Voting closes July 28th. If you did not already register as an SPI contributing member, it is too late for this year. Please also note that the current volume of e-mail on the spi-private mailing list is due entirely to the election and is not at all typical of the list. ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ AgentM [EMAIL PROTECTED] ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ---(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 5: don't forget to increase your free space map settings
Re: [HACKERS] plPHP and plRuby
Peter Eisentraut wrote: Am Montag, 17. Juli 2006 03:18 schrieb Joshua D. Drake: We were going to submit plPHP to core for inclusion but it is not ready yet. Is there enough interest in plRuby to get it where it needs to be for possible inclusion into core? Considering that PL/Java effectively just got shot down, I don't see any hope for these. PLRuby is written in C. 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] plPHP and plRuby
Peter Eisentraut wrote: Andrew Dunstan wrote: But the reasons that applied to PL/Java (masses of non-C code was the main one) probably don't apply in these 2 cases. I don't think it's the amount of non-C code; it's the amount of code that no one understands. Plus, an argument *for* inclusion was build farm coverage, which I understand will be solved in a different way, applicable to all external modules. Another argument was buzzword compliance, which doesn't apply to these two new candidates. So in summary, while I have not seen any valid reason for these inclusions, there continue to be some against it. Ahh o.k. not to be argumentative but PHP is huge and RUby gets more then it fair share of press and articles written about it now. Alot of those *enterprises* that used to use Java are migrating to PHP (why I really don't know but that isn't the point). That being said, PLphp is currently a no-op and won't be able to be considered for 8.2 due to portability issues. However PLruby is a valid inclusion and would enhance our portfolio of pl languages nicely. PLruby also has the benefit of not being repulsive to Perl or Python programmers (where is many perl and python guys really don't like the other ;)). 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] plPHP and plRuby
Peter Eisentraut wrote: Joshua D. Drake wrote: PLRuby is written in C. Specifically on the matter of PL/Ruby -- and if you're trying to be such an advocate about it, you should at least spell it right -- I have never seen the author particularly active within this community, so I have my doubts whether the development processes will integrate well. In fact, shouldn't the inclusion request come from the author in the first place? That is a good point. However in this case, it was CMD that worked with the Author to change the license, specifically for this case. I don't think the author really had any intent of submitting it until we approached him. From a personal perspective, I do not care if we include PL/Ruby. I don't use Ruby. I am a Python guy. However I know a lot of Ruby folk that use PostgreSQL. This would be a good way to improve the native Ruby support for PostgreSQL. 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] plPHP and plRuby
And lastly, if we are not going to include these in core, I repeat what I said before: we need to undertake some *serious* evangelising to major packagers to get them to build more than just the core among their standard packages. Andrew I keep seeing this, but what major packagers are we talking about? Actually as I look at this, the only major distribution (that is not commercial) that doesn't support a lot of PostgreSQL packages is Fedora. Ubuntu Debian Gentoo FreeBSD All have a ton of packages (including plruby). Sincerely, Joshua D. Drake cheers andrew -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] plPHP and plRuby
However, the lack of a maintainer who is an active participant in the community is a serious drawback ... probably even a fatal one. Josh, is there a reason why the PL/Ruby hacker doesn't want to play with us? I don't think it is, doesn't want to play with us. I think he just doesn't :). That being said, we may want to check and see if he participates in PostgreSQLFR (he is french). Also note, that if it were included, CMD would dedicate resources to help keeping it stable etc... 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 5: don't forget to increase your free space map settings
Re: [HACKERS] plPHP and plRuby
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: And if that didn't convince you, I still got PL/sh in the wait ... It seems like there may be enough interest in PL/Ruby to justify including it in our distro, but after taking a look at the package I can see a couple of pretty serious objections: 1. Wrong license. Unless the author can be persuaded to relicense as straight BSD, this discussion is a waste of time. As I mentioned previously, I have already negotiated for a relicense. 2. Coding style. The man does not believe in comments; do we really think anyone else is going to be able to maintain his work? Yes, this was one of my concerns. Sincerely, Joshua D. Drake regards, tom lane -- === 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 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] plPHP and plRuby
Peter Eisentraut wrote: Hannu Krosing wrote: So we would have src/pl/plphp/README.TXT src/pl/pljava/README.TXT src/pl/plj/README.TXT and anybody looking for pl-s would find the info in a logical place It could be interesting to have something like this: ./configure --with-plruby and it would actually fetch the latest plruby sources from the net and build. Ala Ports. This would take some organization of course, but it would be an relatively easy way to increase our core base without bloating core. 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] contrib promotion?
So I would like either some mention of the more useful/stable modules in core docs or a way for contrib modules to become 'official' add-on modules (like PL-s are). This is actually an issue that goes way beyond pgcrypto. I think the manual should formally mention both /contrib and pgFoundry.org as someplace to get add-on features. An even better long-term solution would be something akin to CPAN, but I'm not holding my breath for that... The manual does talk about pgFoundry, especially in 8.2 (that was my patch ;)). It talks about it in 8.1 as well but it is not as apparent. Joshua D. Drake Full merge into core would fix this also, but indeed there is not many techical reasons for it. (And editing pg_proc.h is PITA - I'd consider it technical reason against it ;) -- marko ---(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 5: don't forget to increase your free space map settings
Re: [HACKERS] hot standby system
Is this possible today in a stable and robust way? If so, can we document the procedure? If not, should we alter the documentation so it's not misleading? I've had several people ask me where to enable the hot standby feature, not realizing that PostgreSQL only has some of the raw materials that could be used to architect such a thing. Well it works fine depending on how you set it up :) Please feel free to submit a patch to the docs. Sincerely, Joshua D. Drake Thanks! - Chris [1] http://www.postgresql.org/docs/8.1/interactive/backup-online.html ---(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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
