Re: [GENERAL] pl/java for postgresql 9.2
the problem is that there are no 9.2 binaries for pl/java for windows. Building them for Mac/Unix wasn't too difficult. I've spent 2 days trying to get them building on Windows with no success. Surely someone out there's using pl/java on PostgreSQL 9.2? -- Forwarded message -- From: Pavel Stehule pavel.steh...@gmail.com Date: Fri, Feb 8, 2013 at 12:32 AM Subject: Re: [GENERAL] pl/java for postgresql 9.2 To: Marc Brazeau litespeedm...@gmail.com Cc: pgsql-general@postgresql.org Hello 2013/2/7 Marc Brazeau litespeedm...@gmail.com: Hoping someone can help me here. I'm trying to get pl/java running under Postgres 9.2. Doing so was relatively easy on the Mac. But on Windows, its turning out to be quite problematic. There are no recent binaries available, and if I try with the ones on pgFoundry, I get the following error: ERROR: incompatible library C:/Program Files/PostgreSQL/9.2/lib/pljava.dll: version mismatch DETAIL: Server is version 9.2, library is version 9.1. You cannot to mix libraries and extensions for different mayor PostgreSQL versions DETAIL: Server is version 9.2, library is version 9.1. Regards Pavel Stehule
[GENERAL] pl/java for postgresql 9.2
Hoping someone can help me here. I'm trying to get pl/java running under Postgres 9.2. Doing so was relatively easy on the Mac. But on Windows, its turning out to be quite problematic. There are no recent binaries available, and if I try with the ones on pgFoundry, I get the following error: ERROR: incompatible library C:/Program Files/PostgreSQL/9.2/lib/pljava.dll: version mismatch DETAIL: Server is version 9.2, library is version 9.1.
Re: [GENERAL] pl/java for postgresql 9.2
Hello 2013/2/7 Marc Brazeau litespeedm...@gmail.com: Hoping someone can help me here. I'm trying to get pl/java running under Postgres 9.2. Doing so was relatively easy on the Mac. But on Windows, its turning out to be quite problematic. There are no recent binaries available, and if I try with the ones on pgFoundry, I get the following error: ERROR: incompatible library C:/Program Files/PostgreSQL/9.2/lib/pljava.dll: version mismatch DETAIL: Server is version 9.2, library is version 9.1. You cannot to mix libraries and extensions for different mayor PostgreSQL versions DETAIL: Server is version 9.2, library is version 9.1. Regards Pavel Stehule -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pl/java status
Greg Smith wrote: John R Pierce wrote: is pl/java kind of dead? I don't see much activity since years ago. this page seems quite out of date, talking about 1.1.0b1 released, but the foundry has 1.4.0 from 2008 that supports 8.3. only The last set of commits there was about 9 months ago, so it's not quite as dead as it appears. The code in CVS supports 8.4, there just hasn't been an official release in a while: http://pgfoundry.org/tracker/?func=detailatid=335aid=1010695group_id=138 There are a couple of bugs to note at http://pgfoundry.org/tracker/?atid=334group_id=138func=browse like lack of support for JDK 1.6 and some known complier issues. is there a pl/java mail list? I've started to begin to commence to try to compile this stuff, I checked out the whole thing from CVS and when I run make, I'm getting an error that there's missing files in the postgres tree. I'm using the 8.4-community tarball for 64bit postgresql from the postgres website, am I instead going to have to build my own? ~/org.postgresql.pljava]$ gmake gmake[1]: Entering directory `/export/home/piercej/org.postgresql.pljava/build/classes/pljava' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/export/home/piercej/org.postgresql.pljava/build/classes/pljava' gmake[1]: Entering directory `/export/home/piercej/org.postgresql.pljava/build/classes/deploy' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/export/home/piercej/org.postgresql.pljava/build/classes/deploy' gmake[1]: Entering directory `/export/home/piercej/org.postgresql.pljava/build/objs' /usr/postgres/8.4-community/lib/64/pgxs/src/makefiles/pgxs.mk:59: /usr/postgres/8.4-community/lib/64/pgxs/src/makefiles/../../src/Makefile.global: No such file or directory /usr/postgres/8.4-community/lib/64/pgxs/src/makefiles/pgxs.mk:84: /usr/postgres/8.4-community/lib/64/pgxs/src/makefiles/../../src/Makefile.shlib: No such file or directory gmake[1]: *** No rule to make target `/usr/postgres/8.4-community/lib/64/pgxs/src/makefiles/../../src/Makefile.shlib'. Stop. gmake[1]: Leaving directory `/export/home/piercej/org.postgresql.pljava/build/objs' gmake: *** [c_all] Error 2 this is on Solaris 10, UltraSparc, with SunStudio installed. the postgres is the 8.4 community build, but I do note its only 8.4.1, and I really should upgrade it to 8.4.3 20 mins later, upgraded to 8.4.3, and still getting same error. pg_config says... $ pg_config BINDIR = /usr/postgres/8.4-community/bin/64 DOCDIR = /usr/postgres/8.4-community/share/doc HTMLDIR = /usr/postgres/8.4-community/share/doc INCLUDEDIR = /usr/postgres/8.4-community/include PKGINCLUDEDIR = /usr/postgres/8.4-community/include INCLUDEDIR-SERVER = /usr/postgres/8.4-community/include/server LIBDIR = /usr/postgres/8.4-community/lib/64 PKGLIBDIR = /usr/postgres/8.4-community/lib/64 LOCALEDIR = /usr/postgres/8.4-community/share/locale MANDIR = /usr/postgres/8.4-community/man SHAREDIR = /usr/postgres/8.4-community/share SYSCONFDIR = /usr/postgres/8.4-community/etc PGXS = /usr/postgres/8.4-community/lib/64/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--prefix=/usr/postgres/8.4-community' '--exec-prefix=/usr/postgres/8.4-community' '--bindir=/usr/postgres/8.4-community/bin/64' '--libexecdir=/usr/postgres/8.4-community/bin/64' '--sbindir=/usr/postgres/8.4-community/bin/64' '--datadir=/usr/postgres/8.4-community/share' '--sysconfdir=/usr/postgres/8.4-community/etc' '--mandir=/usr/postgres/8.4-community/man' '--libdir=/usr/postgres/8.4-community/lib/64' '--includedir=/usr/postgres/8.4-community/include' '--sharedstatedir=/var/postgres/8.4-community' '--localstatedir=/var/postgres/8.4-community' '--with-system-tzdata=/usr/share/lib/zoneinfo' '--enable-nls' '--with-docdir=/usr/postgres/8.4-community/doc' '--with-python' '--with-pam' '--with-openssl' '--with-libedit-preferred' '--with-libxml' '--with-libxslt' '--with-gssapi' '--enable-thread-safety' '--enable-dtrace' 'DTRACEFLAGS=-64' '--with-includes=/zstore/pgsql/pg84b1/proto/root_sparc/usr/include:/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/include:/usr/sfw/include' '--with-tclconfig=/usr/sfw/lib' '--with-libs=/zstore/pgsql/pg84b1/proto/root_sparc/usr/lib/64:/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/lib/64:/usr/lib/64:/usr/sfw/lib/64' 'CC=/opt/SUNWspro/SS11/bin/cc' 'CFLAGS=-xO3 -xarch=v9 -dalign -Wc,-Qiselect-regsym=0 -xspace -W0,-Lt -W2,-Rcond_elim -Xa -xildoff ' 'LDFLAGS=-L/zstore/pgsql/pg84b1/proto/root_sparc/usr/lib/64 -L/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/lib/64 -L/usr/sfw/lib/64' 'CPPFLAGS=-I/zstore/pgsql/pg84b1/proto/root_sparc/usr/include -I/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/include -I/usr/sfw/include' CC = /opt/SUNWspro/SS11/bin/cc CPPFLAGS = -I/zstore/pgsql/pg84b1/proto/root_sparc/usr/include -I/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/include -I/usr/sfw/include -I/usr/include/libxml2
Re: [GENERAL] pl/java status
On Wed, 2010-04-14 at 22:53 -0400, Bruce Momjian wrote: Damian Carey wrote: On Thu, Apr 15, 2010 at 6:18 AM, John R Pierce pie...@hogranch.com wrote: Joshua D. Drake wrote: Mostly, I think you will find that the back end developers aren't fond of Java and thus, it doesn't get much love. There is a reason that plPerl is king in this community (and I don't even like Perl). Java2perl anyone ? http://search.cpan.org/~philcrow/Java-Javap-0.04/bin/java2perl6 (99% joking) And if you think positively a 14hour TZ difference is really only 10 if you go the other way. Is PL/J still being developed? I can't find it myself, but was curious. Not as far as I know. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pl/java status
On Wed, 2010-04-14 at 13:41 +0800, Craig Ringer wrote: John R Pierce wrote: is pl/java kind of dead? I don't see much activity since years ago. I've been a bit worried about that myself. With OpenJDK and a GPL java, it makes a lot of sense to make Java a first-class PL in PostgreSQL. There's a fair bit of activity from Java-using users, and there's not really much reason Java should be restricted to the client side when the same language can work well server-side too. Not to mention all those Oracle users out there who're hooked on the stuff. Of course, Java is extremely thread-happy and PostgreSQL is extremely *not*, so perhaps there are reasons it doesn't seem to see much work. If it's anything like working on an embedded Python interpreter... Mostly, I think you will find that the back end developers aren't fond of Java and thus, it doesn't get much love. There is a reason that plPerl is king in this community (and I don't even like Perl). Joshua D. Drake -- Craig Ringer -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pl/java status
Joshua D. Drake wrote: Mostly, I think you will find that the back end developers aren't fond of Java and thus, it doesn't get much love. There is a reason that plPerl is king in this community (and I don't even like Perl). yeah, understood. I'm getting the request 2nd hand, from someone in a TZ 14 hours different than my own (big company, many left hands)... so info is trickling to me. apparently the requester is comfortable programming in Java, and needs to do some sorta-statistical calculations inside a function used in a join of some 73 columns, which will get used by some reporting software... the database in question was ported from a different rdbms where this was a single flat table rather than a several way join, and ... well... thats all I know so far. I've already suggested plpgsql and/or plperl. I'm going to take a stab at building the CVS head of pljava on solaris sparc 64bit tonight or tomorrow. it appears the 64bit community builds of PG 8.4 were built with sunstudio 11, pg_config lists CC = /net/grok/ontools/onnv-tools/SUNWspro/SS11/bin/cc CPPFLAGS = -I/zstore/pgsql/pg84b1/proto/root_sparc/usr/include -I/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/include -I/usr/sfw/include -I/usr/include/libxml2 -I/zstore/pgsql/pg84b1/proto/root_sparc/usr/include -I/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/include -I/usr/sfw/include CFLAGS = -xO3 -xarch=v9 -dalign -Wc,-Qiselect-regsym=0 -xspace -W0,-Lt -W2,-Rcond_elim -Xa -xildoff CFLAGS_SL = -KPIC LDFLAGS = -L/zstore/pgsql/pg84b1/proto/root_sparc/usr/lib/64 -L/zstore/pgsql/pg84b1/proto/root_sparc/usr/sfw/lib/64 -L/usr/sfw/lib/64 -L/usr/lib -L/zstore/pgsql/pg84b1/proto/root_sparc/usr/lib/64 -L/usr/lib/64 -L/usr/sfw/lib/64 -Wl,-R'/usr/postgres/8.4-community/lib/64' It appears I have Sun C 5.9 at my disposal, not sure which version of sunstudio this is from. $ /opt/SUNWspro/bin/cc -V cc: Sun C 5.9 SunOS_sparc Patch 124867-12 2009/11/22 wish me luck :) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pl/java status
On Thu, Apr 15, 2010 at 6:18 AM, John R Pierce pie...@hogranch.com wrote: Joshua D. Drake wrote: Mostly, I think you will find that the back end developers aren't fond of Java and thus, it doesn't get much love. There is a reason that plPerl is king in this community (and I don't even like Perl). Java2perl anyone ? http://search.cpan.org/~philcrow/Java-Javap-0.04/bin/java2perl6 (99% joking) And if you think positively a 14hour TZ difference is really only 10 if you go the other way. Cheers, -Damian -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pl/java status
Damian Carey wrote: On Thu, Apr 15, 2010 at 6:18 AM, John R Pierce pie...@hogranch.com wrote: Joshua D. Drake wrote: Mostly, I think you will find that the back end developers aren't fond of Java and thus, it doesn't get much love. There is a reason that plPerl is king in this community (and I don't even like Perl). Java2perl anyone ? http://search.cpan.org/~philcrow/Java-Javap-0.04/bin/java2perl6 (99% joking) And if you think positively a 14hour TZ difference is really only 10 if you go the other way. Is PL/J still being developed? I can't find it myself, but was curious. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] pl/java status
is pl/java kind of dead? I don't see much activity since years ago. I note the pgfoundry page, http://pgfoundry.org/projects/pljava/?readme the link to the project home page http://wiki.tada.se/display/pljava/Home is broken this page seems quite out of date, talking about 1.1.0b1 released, but the foundry has 1.4.0 from 2008 that supports 8.3. only -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pl/java status
John R Pierce wrote: is pl/java kind of dead? I don't see much activity since years ago. this page seems quite out of date, talking about 1.1.0b1 released, but the foundry has 1.4.0 from 2008 that supports 8.3. only The last set of commits there was about 9 months ago, so it's not quite as dead as it appears. The code in CVS supports 8.4, there just hasn't been an official release in a while: http://pgfoundry.org/tracker/?func=detailatid=335aid=1010695group_id=138 There are a couple of bugs to note at http://pgfoundry.org/tracker/?atid=334group_id=138func=browse like lack of support for JDK 1.6 and some known complier issues. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.us -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pl/java status
Greg Smith wrote: John R Pierce wrote: is pl/java kind of dead? I don't see much activity since years ago. this page seems quite out of date, talking about 1.1.0b1 released, but the foundry has 1.4.0 from 2008 that supports 8.3. only The last set of commits there was about 9 months ago, so it's not quite as dead as it appears. The code in CVS supports 8.4, there just hasn't been an official release in a while: http://pgfoundry.org/tracker/?func=detailatid=335aid=1010695group_id=138 There are a couple of bugs to note at http://pgfoundry.org/tracker/?atid=334group_id=138func=browse like lack of support for JDK 1.6 and some known complier issues. k. the guys who asked me are probably fine with java 1.5, but they definately want to use 8.4. on solaris 10 sparc :) does the package contain a test suite so I'm sure its functional if I build it? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pl/java status
John R Pierce wrote: is pl/java kind of dead? I don't see much activity since years ago. I've been a bit worried about that myself. With OpenJDK and a GPL java, it makes a lot of sense to make Java a first-class PL in PostgreSQL. There's a fair bit of activity from Java-using users, and there's not really much reason Java should be restricted to the client side when the same language can work well server-side too. Not to mention all those Oracle users out there who're hooked on the stuff. Of course, Java is extremely thread-happy and PostgreSQL is extremely *not*, so perhaps there are reasons it doesn't seem to see much work. If it's anything like working on an embedded Python interpreter... -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pl/java in 8.4 bet1 sources compilation failed
Kris Jurka wrote: Craig Ringer wrote: Perhaps a stupid question, but isn't the `-source' parameter to javac intended to mask new features and such for just the purpose of compiling older sources on a new JDK? The -source argument only controls language features, not interface/class definitions. [snip] Ah. Thanks for that very enlightening and helpful explanation - I really appreciate your taking the time. It's interesting that the JDK presents these issues to driver developers, but I see how there's no easy way around it given that Java offers no way to declare default implementations of methods in interfaces (iow: no multiple inheritance) so the JDBC interfaces can't provide stubs. Argh, if only Java had scope-based object lifetime with prompt finalization (think C++ stack-based objects) and multiple inheritance... -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pl/java in 8.4 bet1 sources compilation failed
2009/5/28 Kris Jurka bo...@ejurka.com: On Wed, 27 May 2009, Emanuel Calvo Franco wrote: Hi community, I'm trying to compile pl/java sources for 8.4 beta1 (for a test) but it gives me 20 errors at the end: To build against 8.4 you need pljava from CVS. Also pljava can only be built with the 1.4 or 1.5 JDK, not with the 1.6 version you are using. Oh! Ok. I don't have access to CVS, i think if a want to make my experiment i must use 8.3.7. Thanks Kris and Craig! -- Emanuel Calvo Franco Sumate al ARPUG ! ( www.arpug.com.ar) ArPUG / AOSUG Member -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pl/java in 8.4 bet1 sources compilation failed
On Fri, May 29, 2009 at 1:19 AM, Kris Jurka bo...@ejurka.com wrote: To build against 8.4 you need pljava from CVS. Also pljava can only be built with the 1.4 or 1.5 JDK, not with the 1.6 version you are using. is it a lot of work to make it 1.6 friendly ? can I help? -- GJ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pl/java in 8.4 bet1 sources compilation failed
another question, what about tmdb ? it requires java6, so I assumed that jdbc is 1.6 friendly odd. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pl/java in 8.4 bet1 sources compilation failed
On Fri, May 29, 2009 at 09:48:42AM -0300, Emanuel Calvo Franco wrote: 2009/5/28 Kris Jurka bo...@ejurka.com: On Wed, 27 May 2009, Emanuel Calvo Franco wrote: Hi community, I'm trying to compile pl/java sources for 8.4 beta1 (for a test) but it gives me 20 errors at the end: To build against 8.4 you need pljava from CVS. Also pljava can only be built with the 1.4 or 1.5 JDK, not with the 1.6 version you are using. Oh! Ok. I don't have access to CVS, i think if a want to make my experiment i must use 8.3.7. If you have access to a compiler but not CVS or git, you can get one of the daily tarballs. Are you *sure* you can't use CVS or git, though? Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pl/java in 8.4 bet1 sources compilation failed
2009/5/29 David Fetter da...@fetter.org: On Fri, May 29, 2009 at 09:48:42AM -0300, Emanuel Calvo Franco wrote: 2009/5/28 Kris Jurka bo...@ejurka.com: On Wed, 27 May 2009, Emanuel Calvo Franco wrote: Hi community, I'm trying to compile pl/java sources for 8.4 beta1 (for a test) but it gives me 20 errors at the end: To build against 8.4 you need pljava from CVS. Also pljava can only be built with the 1.4 or 1.5 JDK, not with the 1.6 version you are using. Oh! Ok. I don't have access to CVS, i think if a want to make my experiment i must use 8.3.7. If you have access to a compiler but not CVS or git, you can get one of the daily tarballs. Are you *sure* you can't use CVS or git, though? Hey, David! :) I don't have access yet to the git and CVS repos from these machines, because the ports are closed. :S Maybe the daily tarball would be usefull at this case. However, i must touch a little to make it compilable with 1.6 java platform OR maybe downgrade it to 1.5. I'm doing some rare things and it will be great if I could perform these on 8.4, despite I'll not use in 'prima facie' the new features of it. -- Emanuel Calvo Franco Sumate al ARPUG ! ( www.arpug.com.ar) ArPUG / AOSUG Member -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pl/java in 8.4 bet1 sources compilation failed
David Fetter wrote: If you have access to a compiler but not CVS or git, you can get one of the daily tarballs. Are you *sure* you can't use CVS or git, though? The problem is pljava, not postgresql. pljava doesn't have a daily tarball or a git repo, so CVS is the only option at the moment. Kris Jurka -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pl/java in 8.4 bet1 sources compilation failed
Grzegorz Jaśkiewicz wrote: On Fri, May 29, 2009 at 1:19 AM, Kris Jurka bo...@ejurka.com wrote: To build against 8.4 you need pljava from CVS. Also pljava can only be built with the 1.4 or 1.5 JDK, not with the 1.6 version you are using. is it a lot of work to make it 1.6 friendly ? can I help? It depends how it's done. It would be easy to make pljava require 1.6 and just add stubs that throw unimplemented exceptions for the new methods. Building against both 1.4/1.5 (JDBC 3) and 1.6 (JDBC 4) would require a more complicated conditional compilation system like that provided with the standard JDBC driver. Kris Jurka -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pl/java in 8.4 bet1 sources compilation failed
Grzegorz Jaśkiewicz wrote: another question, what about tmdb ? it requires java6, so I assumed that jdbc is 1.6 friendly odd. I have no idea what tmdb is. JDK 1.6 includes the JDBC 4 API while 1.4 and 1.5 include the JDBC 3 API. So building pljava doesn't implement all of the JDBC 4 API and can't be built with JDK 1.6. It will run under a 1.6 JVM as long as you don't use methods that are new in JDBC 4. Kris Jurka -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pl/java in 8.4 bet1 sources compilation failed
Kris Jurka wrote: Grzegorz Jaśkiewicz wrote: On Fri, May 29, 2009 at 1:19 AM, Kris Jurka bo...@ejurka.com wrote: To build against 8.4 you need pljava from CVS. Also pljava can only be built with the 1.4 or 1.5 JDK, not with the 1.6 version you are using. is it a lot of work to make it 1.6 friendly ? can I help? It depends how it's done. It would be easy to make pljava require 1.6 and just add stubs that throw unimplemented exceptions for the new methods. Building against both 1.4/1.5 (JDBC 3) and 1.6 (JDBC 4) would require a more complicated conditional compilation system like that provided with the standard JDBC driver. Perhaps a stupid question, but isn't the `-source' parameter to javac intended to mask new features and such for just the purpose of compiling older sources on a new JDK? -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pl/java in 8.4 bet1 sources compilation failed
Craig Ringer wrote: Perhaps a stupid question, but isn't the `-source' parameter to javac intended to mask new features and such for just the purpose of compiling older sources on a new JDK? The -source argument only controls language features, not interface/class definitions. java.sql.* provides interfaces that drivers must implement. When they add new functions to those interfaces you have to implement those, otherwise the compile fails saying that the class doesn't implement the specified interface. Sometimes you can implement new interface functions so that the code can compile in either version, but not always. Consider the following two cases: 1) JDBC4 has added a new method to java.sql.Array named void free(). This can be implemented for JDBC3 and there's no problem that the JDBC3 class implements an additional method that's only required by JDBC4. The code can be compiled against either JDK version. 2) JDBC4 has added a new interface, java.sql.SQLXML, and added methods to java.sql.ResultSet to retrieve SQLXML objects. You can't add a method SQLXML getSQLXML(int) to your JDBC3 class because it doesn't know anything about SQLXML at all because it isn't defined by JDBC3. For this we must add code that is only compiled if we're building with a JDK that has JDBC4. The JDBC driver does this by defining a hierarchy: AbstractJdbc2ResultSet |__Jdbc2ResultSet |__AbstractJdbc3ResultSet |__Jdbc3ResultSet |__AbstractJdbc4ResultSet |__Jdbc4ResultSet AbstractJdbc4ResultSet will have the getSQLXML method and the JdbcXResultSet classes will be just stubs that officially implement the java.sql.ResultSet interface. If we're building a JDBC3 driver we'll compile AbstractJdbc2ResultSet, AbstractJdbc3ResultSet, and Jdbc3ResultSet and when asked for a ResultSet instance we'll return a Jdbc3ResultSet. When building a JDBC4 driver we'll then exclude Jdbc3ResultSet and compile AbstractJdbc4ResultSet and Jdbc4ResultSet and when asked for ResultSet instance we'll return a Jdbc4ResultSet. By using this inheritance we can conditionally compile entire classes which is easy to do with ant rather than trying to implement something like #ifdef which is ugly to do with ant's copy with filtering task. Unfortunately pljava currently has no such infrastructure. Kris Jurka -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pl/java in 8.4 bet1 sources compilation failed
Emanuel Calvo Franco wrote: Hi community, I'm trying to compile pl/java sources for 8.4 beta1 (for a test) but it gives me 20 errors at the end: Which compiler and JDK are you using? ... and no, there isn't really any way to ignore the lib version; it wouldn't work, because 8.3 and 8.4 aren't binary compatible for server plugins like PL languages. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Pl/java in 8.4 bet1 sources compilation failed
On Wed, 27 May 2009, Emanuel Calvo Franco wrote: Hi community, I'm trying to compile pl/java sources for 8.4 beta1 (for a test) but it gives me 20 errors at the end: To build against 8.4 you need pljava from CVS. Also pljava can only be built with the 1.4 or 1.5 JDK, not with the 1.6 version you are using. Kris Jurka -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Pl/java in 8.4 bet1 sources compilation failed
Hi community, I'm trying to compile pl/java sources for 8.4 beta1 (for a test) but it gives me 20 errors at the end: ... /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/ObjectResultSet.java:290: reference to updateBlob is ambiguous, both method updateBlob(int,java.sql.Blob) in java.sql.ResultSet and method updateBlob(int,java.io.InputStream) in java.sql.ResultSet match this.updateBlob(columnIndex, new BlobValue(x, length)); ^ /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/ObjectResultSet.java:320: reference to updateClob is ambiguous, both method updateClob(int,java.sql.Clob) in java.sql.ResultSet and method updateClob(int,java.io.Reader) in java.sql.ResultSet match this.updateClob(columnIndex, new ClobValue(x, length)); ^ /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SQLOutputToTuple.java:35: org.postgresql.pljava.jdbc.SQLOutputToTuple is not abstract and does not override abstract method writeSQLXML(java.sql.SQLXML) in java.sql.SQLOutput public class SQLOutputToTuple implements SQLOutput ^ /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SPIConnection.java:42: org.postgresql.pljava.jdbc.SPIConnection is not abstract and does not override abstract method createStruct(java.lang.String,java.lang.Object[]) in java.sql.Connection public class SPIConnection implements Connection ^ /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SQLInputFromChunk.java:40: org.postgresql.pljava.jdbc.SQLInputFromChunk is not abstract and does not override abstract method readRowId() in java.sql.SQLInput public class SQLInputFromChunk implements SQLInput ^ /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SPIStatement.java:25: org.postgresql.pljava.jdbc.SPIStatement is not abstract and does not override abstract method isPoolable() in java.sql.Statement public class SPIStatement implements Statement ^ /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SPIPreparedStatement.java:38: org.postgresql.pljava.jdbc.SPIPreparedStatement is not abstract and does not override abstract method setNClob(int,java.io.Reader) in java.sql.PreparedStatement public class SPIPreparedStatement extends SPIStatement implements PreparedStatement ^ /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/TriggerResultSet.java:22: org.postgresql.pljava.jdbc.TriggerResultSet is not abstract and does not override abstract method updateNClob(java.lang.String,java.io.Reader) in java.sql.ResultSet public class TriggerResultSet extends SingleRowResultSet ^ /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SyntheticResultSetMetaData.java:20: org.postgresql.pljava.jdbc.SyntheticResultSetMetaData is not abstract and does not override abstract method isWrapperFor(java.lang.Class) in java.sql.Wrapper public class SyntheticResultSetMetaData extends AbstractResultSetMetaData ^ /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/ClobValue.java:23: org.postgresql.pljava.jdbc.ClobValue is not abstract and does not override abstract method getCharacterStream(long,long) in java.sql.Clob public class ClobValue extends Reader implements Clob ^ /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SPIParameterMetaData.java:16: org.postgresql.pljava.jdbc.SPIParameterMetaData is not abstract and does not override abstract method isWrapperFor(java.lang.Class) in java.sql.Wrapper public class SPIParameterMetaData implements ParameterMetaData ^ /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SPIResultSetMetaData.java:21: org.postgresql.pljava.jdbc.SPIResultSetMetaData is not abstract and does not override abstract method isWrapperFor(java.lang.Class) in java.sql.Wrapper public class SPIResultSetMetaData extends AbstractResultSetMetaData ^ /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SingleRowReader.java:22: org.postgresql.pljava.jdbc.SingleRowReader is not abstract and does not override abstract method updateNClob(java.lang.String,java.io.Reader) in java.sql.ResultSet public class SingleRowReader extends SingleRowResultSet ^ /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/SingleRowWriter.java:26: org.postgresql.pljava.jdbc.SingleRowWriter is not abstract and does not override abstract method updateNClob(java.lang.String,java.io.Reader) in java.sql.ResultSet public class SingleRowWriter extends SingleRowResultSet ^ /home/ubuntu/Desktop/pljava-1.4.0/src/java/pljava/org/postgresql/pljava/jdbc/BlobValue.java:20: org.postgresql.pljava.jdbc.BlobValue is not abstract and does not override abstract method getBinaryStream(long,long) in java.sql.Blob public
[GENERAL] pl/java on Solaris
I am migrating an 8.3 database from Windows to Solaris. We are using pl/java and I went through the installation process for this on Windows. I'm building Solaris from the source and when running ./configure, I don't see a switch to include pl/java. Java is in my path too so it should allow me to install it (if it follows the same pattern as Windows). I don't see a pljava file in my share directory like I do on Windows. Is pl/java not included when compiling from source? Jon -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pl/java on Solaris
On Thu, Apr 10, 2008 at 5:31 AM, Roberts, Jon [EMAIL PROTECTED] wrote: I am migrating an 8.3 database from Windows to Solaris. We are using pl/java and I went through the installation process for this on Windows. I'm building Solaris from the source and when running ./configure, I don't see a switch to include pl/java. Java is in my path too so it should allow me to install it (if it follows the same pattern as Windows). I don't see a pljava file in my share directory like I do on Windows. Is pl/java not included when compiling from source? here is the user doc from cvs. I might help. http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/pljava/org.postgresql.pljava/docs/userguide.html?rev=1.15content-type=text/plain -- Regards, Richard Broersma Jr. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pl/java on Solaris
Roberts, Jon napsal(a): I don't see a pljava file in my share directory like I do on Windows. Is pl/java not included when compiling from source? pl/java is not part of core like pl/pgPerl... You need to download it separately from http://pgfoundry.org/projects/pljava/ Zdenek -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pl/java on Solaris
On Thu, 10 Apr 2008, Roberts, Jon [EMAIL PROTECTED] writes: I am migrating an 8.3 database from Windows to Solaris. We are using pl/java and I went through the installation process for this on Windows. I'm building Solaris from the source and when running ./configure, I don't see a switch to include pl/java. Java is in my path too so it should allow me to install it (if it follows the same pattern as Windows). I don't see a pljava file in my share directory like I do on Windows. Is pl/java not included when compiling from source? PL/java[1] is a separate PL project, not builtin to PostgreSQL. I don't know about official Windows installation binaries, they would be bringing it by default. [1] http://pljava.projects.postgresql.org/ Regards. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pl/java on Solaris
Volkan YAZICI [EMAIL PROTECTED] writes: On Thu, 10 Apr 2008, Roberts, Jon [EMAIL PROTECTED] writes: I don't see a pljava file in my share directory like I do on Windows. Is pl/java not included when compiling from source? PL/java[1] is a separate PL project, not builtin to PostgreSQL. The Windows installer actually aggregates quite a few projects besides core PG. If you want to build from source you'll need to collect a number of tarballs, depending on what features you were using. The installer documentation can probably tell you where they all came from. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] pl/java tutorials
Hello dudes!!! I would like to know where can i find pl/java tutorials or books. Thanks. -- View this message in context: http://www.nabble.com/pl-java-tutorials-tp15306636p15306636.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. ---(end of broadcast)--- TIP 6: explain analyze is your friend
[GENERAL] Pl/Java broken since Postgresql 8.3-rc1
Hi, I'm following the 8.3 beta releases for some time now, mostly using the Win32 with Installer package. 8.3beta3 and 4 have worked perfectly with the provided pljava ddl, just with 8.3-rc1 it doesn't work anymore. i.e. 1. automatic installation of Pl/Java via Installer fails. 2. manual Installation via CREATE FUNCTION java_call_handler() RETURNS language_handler AS 'pljava', 'java_call_handler' LANGUAGE c; raises the following error: ERROR: could not load library C:/Programme/PostgreSQL/8.3-rc1/lib/pljava.dll: unknown error 127 Tested on two different WinXP machines with JDK 1.6. Regards, Jan Ischebeck ---(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
[GENERAL] PL/Java vs PL/pgSQL
1. Who is faster? 2. Who is recomended? ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] PL/java?
* [EMAIL PROTECTED] (Randal L. Schwartz) wrote: | | If you'd just stop saying things that can't be backed up, I wouldn't | have to keep responding. ;-) | Where is your proof that mod_perl is slower than most any j2ee | application? I don't like to generalize either. I've been on two projects where we have replaced Perl applications with Java applications. The first one was a content management system and the second was an online dating application(like match.com). In both cases we ended up with Java applications that performed better than the Perl applications. The reasons ? - Maybe it was because our Java developers were better than our Perl developers. - Maybe we had learned something the second time implementing the application. Better architecture, system design, etc. - Maybe Java was better suited for the actual applications. In the end there is however no proof to claim that Java applications are faster than mod_perl applications. But having Java in the PgSQL backend would be nice for some, regardless of how well Java compares to Perl. -- Gunnar Rønning - [EMAIL PROTECTED] Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] PL/java?
Gunnar == Gunnar Rønning [EMAIL PROTECTED] writes: Gunnar In the end there is however no proof to claim that Java applications Gunnar are faster than mod_perl applications. I'll settle for that. Most of the time I've seen benchmarks, it's been more the skillset of the programmers at stake rather than the languages. Gunnar But having Java in the PgSQL backend would be nice for some, Gunnar regardless of how well Java compares to Perl. Yes, I can support that. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] PL/java?
Hi Alex, Saying that mod_perl is slower than any java apps is purely marketing for java. An other guy told me that one day, I just bench it to show him how java developper just talk marketing. So the result was that with small users the performance was the same and with many user mod_perl is really speediest. Secondly mod_perl doesn't crash the system, under Linux using Java is a waste of time and a leak of memory ! Marketing is probably why daniel talk about Win$ When first Java was out it was called the Perl killer, so after many years Perl is most uses than Java, ask you why ??? For your other words what you do in Java can be done in perl more quickly more efficiently and with writing many less lines ! An other example is the Oracle XML/SQL Servlet that it was plan to use in my company. After hearing too many marketing words I write the same in perl in 3 days and extend the possibility with no limits. Now they're using Perl, ask you why ? This is use in the entreprise commercial application that I think you call entreprise level ! At this time Perl is the only really portable language over any OS. In my opinion PL/Java is purely a waste of time but some have time so why not ! Sorry but I can not let you say words like that, we are not newbe :-( In your way I can tell you that before using Perl I also preach for Java :-) But after rewritten many time the same apps with the differents versions of Java and the OS where it should work it ended to decide me: no more Java ! Regards Gilles Darold Alex Knight wrote: Daniel, thank you kindly for your input. However, mod_perl is absolutely slower than most any j2ee application. If all you are doing is keeping a session variable to count number of hits on a web page, then sure, perl is more than sufficient, possibly faster. But when you start doing anything of importance, enterprise level stuff, you need something scalable in ways java can go, but perl just doesn't seem to have _easy_ or sometimes _existant_ ways to implement. How would you go about synchronizing session data on 10 application servers running mod_perl _without_ using the database to mirror that data in memory? It's not very difficult to do it in Java. (Ofcourse, any smart architect would use content switches generally to keep a remote user associated with the initial app server to reduce the necessity of such replication technologies). Not sure how you are associating me with windows, but no, all my server stuff is always *nix. My answer on awt and swing was in reference to someone else who was basing their opinion of java on awt/swing's capabilities. Regardless, applets using awt/swing can be easily run under Linux Mozilla or Netscape, or HotJava, etc. So you can't really say that's enough to assume we're talking about windows. -Knight ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] PL/java?
Hi Gilles, You did not read what I wrote very well. First, I said that mod_perl was slower than most any j2ee application. If you knew what j2ee was, you'd know that it's generally limited to server-side internet apps like servlets, jsps, etc... Not to mention, I do try to give perl credit where due. If java crashes your server, that's because either the vendor that has the jvm incorporated sucks, or your program was written poorly. I have _never_ crashed a system or eaten up memory when everything is properly installed. Java is NOT a cure all language. I honestly feel that because of the way the interpreter is packaged, it can not be used for every single situation, like C could for example. But I feel java would be incredibly appropriate in postgresql. I see it this way. All the people who really know Java's capabilities, and know that it can be used without problem, will want Java in the db. All the others who think java is _always_ slow or java leaks memory or java is a waste of time won't be using the java extensions ANYWAYS. As for perl, I probably came off a little wrong. In a reply to Randal, I did state that I liked perl very much, and I've been developing with it forever. Perl _is_ amazing, and there is no limit to what you can do with it. However, in some cases, Java does things better (just like perl does things faster than Java in certain situations). But perl has had the most uses for so many years because it is easy to learn, not truely object oriented (atleast the past few years have been that way), does not require compiling to simplify the execution process (i.e. fully interpreted), etc. Expand on your enterprise application. A true enterprise application takes more than 3 days time to design and implement. Most real enterprise applications have multiple layers of logic, etc. I don't consider a script that queries a database for a password by 100,000 people a day to really be considered as Enterprise either. If I was new to programming, and I started preaching Java right off the bat, this conversation wouldn't be warranted. In fact, I run into these types of Java developers who go around saying they think Java is the best language ever, etc etc but don't really have the experience to make that claim. Anyways, I really didn't want this to get into my language is better than yours, and let's drop that immediately. My entire purpose here was to help defend the idea of implementing Java as a PL in PGSQL. Anyone else have any comments about the java implementation? -Knight -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Gilles DAROLD Sent: Tuesday, September 04, 2001 3:22 AM To: [EMAIL PROTECTED] Subject: Re: [GENERAL] PL/java? Hi Alex, Saying that mod_perl is slower than any java apps is purely marketing for java. An other guy told me that one day, I just bench it to show him how java developper just talk marketing. So the result was that with small users the performance was the same and with many user mod_perl is really speediest. Secondly mod_perl doesn't crash the system, under Linux using Java is a waste of time and a leak of memory ! Marketing is probably why daniel talk about Win$ When first Java was out it was called the Perl killer, so after many years Perl is most uses than Java, ask you why ??? For your other words what you do in Java can be done in perl more quickly more efficiently and with writing many less lines ! An other example is the Oracle XML/SQL Servlet that it was plan to use in my company. After hearing too many marketing words I write the same in perl in 3 days and extend the possibility with no limits. Now they're using Perl, ask you why ? This is use in the entreprise commercial application that I think you call entreprise level ! At this time Perl is the only really portable language over any OS. In my opinion PL/Java is purely a waste of time but some have time so why not ! Sorry but I can not let you say words like that, we are not newbe :-( In your way I can tell you that before using Perl I also preach for Java :-) But after rewritten many time the same apps with the differents versions of Java and the OS where it should work it ended to decide me: no more Java ! Regards Gilles Darold Alex Knight wrote: Daniel, thank you kindly for your input. However, mod_perl is absolutely slower than most any j2ee application. If all you are doing is keeping a session variable to count number of hits on a web page, then sure, perl is more than sufficient, possibly faster. But when you start doing anything of importance, enterprise level stuff, you need something scalable in ways java can go, but perl just doesn't seem to have _easy_ or sometimes _existant_ ways to implement. How would you go about synchronizing session data on 10 application servers running mod_perl _without_ using the database to mirror that data in memory? It's not very difficult to do it in Java. (Ofcourse, any smart architect
Re: [GENERAL] PL/java?
Python is a great language too. For scripts, I tend to write more python scripts than perl these days, simply because python better suits my needs and the base class library seems larger than perl's after install, not that adding libs aren't easy. But I can write compact scripts without cryptoblinding the user reading the script... Zope is quite powerful too. But Zope still has a long way to travel until it can make it to the Enterprise arena. I know a lot of the Zope developers, and zope.org specifically gets lots of hits, but it's not getting nearly as many as a Bankofamerica.com would get. -Knight -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Adam Manock Sent: Tuesday, September 04, 2001 4:35 AM To: [EMAIL PROTECTED] Subject: Re: [GENERAL] PL/java? After having seen this Perl / Java debate go back and forth... I can't help myself... RANT The answer is Python !!! For the best middleware you're ever likely to integrate with Postgresql : http://www.zope.org To see its enterprise scalability: http://www.zope.org/About To see it taking LOTS of hits: http://ns1.zope.org:82/ To see it NOT using much memory at all: http://ns1.zope.org:82/cgi-bin/zope-track.pl (this one loads kinda slow, maybe cause it's done in Perl?) /RANT The real point here is that programmers are religious about their choice of language, and highly resistant to changing, which is why Postgres supports so many languages! I happen to prefer python, but that's just me. http://www.python.org if you're curious Adam At 06:21 AM 9/4/01, you wrote: Hi Alex, Saying that mod_perl is slower than any java apps is purely marketing for java. An other guy told me that one day, I just bench it to show him how java developper just talk marketing. So the result was that with small users the performance was the same and with many user mod_perl is really speediest. Secondly mod_perl doesn't crash the system, under Linux using Java is a waste of time and a leak of memory ! Marketing is probably why daniel talk about Win$ When first Java was out it was called the Perl killer, so after many years Perl is most uses than Java, ask you why ??? For your other words what you do in Java can be done in perl more quickly more efficiently and with writing many less lines ! An other example is the Oracle XML/SQL Servlet that it was plan to use in my company. After hearing too many marketing words I write the same in perl in 3 days and extend the possibility with no limits. Now they're using Perl, ask you why ? This is use in the entreprise commercial application that I think you call entreprise level ! At this time Perl is the only really portable language over any OS. In my opinion PL/Java is purely a waste of time but some have time so why not ! Sorry but I can not let you say words like that, we are not newbe :-( In your way I can tell you that before using Perl I also preach for Java :-) But after rewritten many time the same apps with the differents versions of Java and the OS where it should work it ended to decide me: no more Java ! Regards Gilles Darold Alex Knight wrote: Daniel, thank you kindly for your input. However, mod_perl is absolutely slower than most any j2ee application. If all you are doing is keeping a session variable to count number of hits on a web page, then sure, perl is more than sufficient, possibly faster. But when you start doing anything of importance, enterprise level stuff, you need something scalable in ways java can go, but perl just doesn't seem to have _easy_ or sometimes _existant_ ways to implement. How would you go about synchronizing session data on 10 application servers running mod_perl _without_ using the database to mirror that data in memory? It's not very difficult to do it in Java. (Ofcourse, any smart architect would use content switches generally to keep a remote user associated with the initial app server to reduce the necessity of such replication technologies). Not sure how you are associating me with windows, but no, all my server stuff is always *nix. My answer on awt and swing was in reference to someone else who was basing their opinion of java on awt/swing's capabilities. Regardless, applets using awt/swing can be easily run under Linux Mozilla or Netscape, or HotJava, etc. So you can't really say that's enough to assume we're talking about windows. -Knight ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] PL/java?
Alex == Alex Knight [EMAIL PROTECTED] writes: Alex You did not read what I wrote very well. First, I said that mod_perl was Alex slower than most any j2ee application. If you knew what j2ee was, Alex you'd know that it's generally limited to server-side internet apps Alex like servlets, jsps, etc... If you'd just stop saying things that can't be backed up, I wouldn't have to keep responding. Where is your proof that mod_perl is slower than most any j2ee application? Alex However, in some cases, Java does things better (just like Alex perl does things faster than Java in certain situations). I'm still waiting for Java does things better to be demonstrated. Alex But perl has had the most uses for so many years because it is Alex easy to learn, not truely object oriented Perl is a hybrid OO language, just like Java. Now if you compare both of them to Smalltalk, I see your point. But Java has primitive types that cannot be subclassed or extended, just like Perl. There's really no difference. Perhaps you've not read Object Oriented Perl by Damian Conway, to see just how rich Perl's object model is, even compared to Java and others. Alex (atleast the past few Alex years have been that way), does not require compiling to Alex simplify the execution process (i.e. fully interpreted), etc. Perl is no more interpreted than Java. Perl's compiler translates the entire program down to bytecodes, and the bytecodes are then executed by the Perl Virtual Machine, just like Java. (I won't bring up any benchmarks here... it's unfair to Java. :) See... it's the nonsense you keep spouting that makes me want to slap you silly. Get a clue. Perl is a serious, mission-critical language, being actively developed by hundreds of people who depend on it to remain stable, fast, and useful. I've seen both. Java has its place. Perl has its place. Stop dissing Perl, because you are apparently unaware of what is actually going on. I guess that would make you a language bigot. Alex Expand on your enterprise application. A true enterprise application Alex takes more than 3 days time to design and implement. Most real Alex enterprise applications have multiple layers of logic, etc. I don't Alex consider a script that queries a database for a password by 100,000 Alex people a day to really be considered as Enterprise either. And many enterprise applications are completely in Perl. cbs.sportsline.com is 90% Perl. Etoys.com was 100% Perl. imdb.com is 100% perl. valueclick.com is 100% Perl. Amazon.com does all their backend processing in Perl. Boeing uses Perl in every step of their cad/cam process... every number defining the 777 airplane was passed through Perl. Alex If I was new to programming, and I started preaching Java Alex right off the bat, this conversation wouldn't be warranted. In Alex fact, I run into these types of Java developers who go around Alex saying they think Java is the best language ever, etc etc but Alex don't really have the experience to make that claim. You smell a bit like that now though, mostly through your ignorance of Perl. Maybe you're not unfounded pro Java, but you are unfounded anti Perl. And I won't allow that here. I'll certainly permit Perl to lose on its technical merits, but I won't let Perl lose through your ignorance of what it actually can be or do. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] PL/java?
| Its not a perception. Java is still a dog. Back it up or back out please. The most scalable and stable enterprise solutions out there are today running Java. In Java you actually get more time to concentrate on removing the real performance bottlenecks of your application. Hehe OK, imagine if the whole of PostgreSQL was written in Java. Yeah, we'd be able to really remove its performance bottlenecks then. Really, I think we're all convinced on that one ;-) Having said that if people want PL/Java then let them write it. Its just another option and that can't hurt... - Andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [WAY OT] Re: [GENERAL] PL/java?
No offense, but I've been developing under your language since nearly it's public conception... and perl is _great_. Frankly, I don't want to argue with you, because you'll simply defend your own creation without reasonably evaluating the situation. But I think everyone needs to remember that we shouldn't make a decision about this because of everyone's political stances behind languages, especially if they haven't had development experience with it. i think that you missed the point that mr. schwartz is trying to make - anything you can do in java, you _can_ do in perl. in my opinion, he isn't trying to say that you _should_ do it in perl. he might do it in perl but, after all, there is more than one way to get things done :) one of the things that i find refreshing about perl is its lack of corporate attitude. perl doesn't have any aspirations to be anything other than what it is. it isn't being driven by corporate marketing forcing it to beat someone else. the only thing that is driving it is the needs and desires of its developers to evolve it to meet the needs of its users. and i do almost all of my server-side development in java! Alex How would you go about synchronizing session data on 10 Alex application servers running mod_perl _without_ using the Alex database to mirror that data in memory? It's not very Alex difficult to do it in Java. are you saying that it isn't very difficult for you to go out and write this yourself in java or are you saying that it isn't difficult for you to use what someone else has already written? if the former and if you want to do something like this in perl you can start with reading the section in the camel book on tcp clients and servers. if you feel that tcp has too high of an overhead then you can read the section on udp clients and servers. if the latter, look on cpan and if what you want isn't there then you can step and contribute. ohmigod, i'm defending perl and guess what? i _still_ do almost all of my server-side development in java! Alex However, mod_perl is absolutely slower than most any Alex j2ee application. If all you are doing is keeping Alex a session variable to count number of hits on a web Alex page, then sure, perl is more than sufficient, Alex possibly faster. But when you start doing anything Alex of importance, enterprise level stuff, you need Alex something scalable in ways java can go, but perl Alex just doesn't seem to have _easy_ or sometimes Alex _existant_ ways to implement. i don't like language bigots. i just don't. most languages are quite capable and anyone that denies the viability of one language is generally uninformed. just because perl doesn't get the four-color glossy press that java gets doesn't mean that it isn't capable it just means it doesn't get the four-color glossy press. just because you don't see something arrive in your box every day trumpeting perl doesn't mean it can't do what you want and do it well. it just means that there isn't anyone out there blowing the horn in your ear. we have already seen on this topic someone spouting off that java was way too slow, that c++ was sooo much better, that having a jvm included in the distribution would make postgres hog memory and crash unexpectedly. all of this without any links to nice evidence. all of this while degrading java based on the performance of one application (tomcat) that pretty much everyone agrees is a dog. personally, i see a _lot_ of similarities between his issues with java and your issues with perl. 7-11 burritos. rjsjr ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [WAY OT] Re: [GENERAL] PL/java?
OK. If I find some time, I'm going to attempt to do some things that java does well, that I think perl can not do easily. -Knight -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert J. Sanford, Jr. Sent: Monday, September 03, 2001 6:02 PM To: [EMAIL PROTECTED] Cc: Randal L. Schwartz Subject: Re: [WAY OT] Re: [GENERAL] PL/java? No offense, but I've been developing under your language since nearly it's public conception... and perl is _great_. Frankly, I don't want to argue with you, because you'll simply defend your own creation without reasonably evaluating the situation. But I think everyone needs to remember that we shouldn't make a decision about this because of everyone's political stances behind languages, especially if they haven't had development experience with it. i think that you missed the point that mr. schwartz is trying to make - anything you can do in java, you _can_ do in perl. in my opinion, he isn't trying to say that you _should_ do it in perl. he might do it in perl but, after all, there is more than one way to get things done :) one of the things that i find refreshing about perl is its lack of corporate attitude. perl doesn't have any aspirations to be anything other than what it is. it isn't being driven by corporate marketing forcing it to beat someone else. the only thing that is driving it is the needs and desires of its developers to evolve it to meet the needs of its users. and i do almost all of my server-side development in java! Alex How would you go about synchronizing session data on 10 Alex application servers running mod_perl _without_ using the Alex database to mirror that data in memory? It's not very Alex difficult to do it in Java. are you saying that it isn't very difficult for you to go out and write this yourself in java or are you saying that it isn't difficult for you to use what someone else has already written? if the former and if you want to do something like this in perl you can start with reading the section in the camel book on tcp clients and servers. if you feel that tcp has too high of an overhead then you can read the section on udp clients and servers. if the latter, look on cpan and if what you want isn't there then you can step and contribute. ohmigod, i'm defending perl and guess what? i _still_ do almost all of my server-side development in java! Alex However, mod_perl is absolutely slower than most any Alex j2ee application. If all you are doing is keeping Alex a session variable to count number of hits on a web Alex page, then sure, perl is more than sufficient, Alex possibly faster. But when you start doing anything Alex of importance, enterprise level stuff, you need Alex something scalable in ways java can go, but perl Alex just doesn't seem to have _easy_ or sometimes Alex _existant_ ways to implement. i don't like language bigots. i just don't. most languages are quite capable and anyone that denies the viability of one language is generally uninformed. just because perl doesn't get the four-color glossy press that java gets doesn't mean that it isn't capable it just means it doesn't get the four-color glossy press. just because you don't see something arrive in your box every day trumpeting perl doesn't mean it can't do what you want and do it well. it just means that there isn't anyone out there blowing the horn in your ear. we have already seen on this topic someone spouting off that java was way too slow, that c++ was sooo much better, that having a jvm included in the distribution would make postgres hog memory and crash unexpectedly. all of this without any links to nice evidence. all of this while degrading java based on the performance of one application (tomcat) that pretty much everyone agrees is a dog. personally, i see a _lot_ of similarities between his issues with java and your issues with perl. 7-11 burritos. rjsjr ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] PL/java?
I'm just wondering if people have thoughts or ideas on this, and if someone is actually working on it, that would be cool. Why would that be cool? Because it's an OO language? If that's the criteria for cool, check out pl/Ruby. It's a pure OO language (java isn't) and is a joy to work with, but YMMV. -sc -- Sean Chittenden PGP signature ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
how that can come, that table locking is faster than versioning? from how i understand versioning it can't be slower. and saying that possible access problems with table can be avoided be specially designing application. God! i must design specially for mysql, being locking whole tables. this page shows that they are low-end even in the mind. they didn't implemet constraints/subselects/views/triggers/full joins, but they've got packed bases and compressed client/server protocol! wow. must be cool. personally, when i tried 7.0.2, with triggers/constraints/views and other cool stuff (transactions!) i said to myself yep, that's the db you need. and now, whatever they say, when i hear somebody doing billing system (!) on mysql, i just shrug my shoulders. in russian it called everybody goes insane his own way. btw, what's related to in-memory quick db, what prevents you from creating memory filesystem and put postgres dbs there? in *bsd it's not a problem, on linux i believe too... On Sun, Aug 26, 2001 at 02:29:55PM +1000, Justin Clift wrote: We can always ask them to change things. The thing which strike me as Sean Chittenden wrote: Has anyone seen this page on Mysql.org comparing PostgreSQL to MySQL: http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html Yeah, I've had a few developers show it to me... the best part -- Denis A. Doroshenko [GPRS engineer] .-._|_ | [Omnitel Ltd., T.Sevcenkos st. 25, Vilnius, Lithuania] | | _ _ _ .| _ | [Phone: +370 9863486 E-mail: [EMAIL PROTECTED]] |_|| | || |||(/_|_ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
yeah, by the way, doing dump/restore not such a bad thing, as mysql may say. supporting old stuff is sometimes horrible. look at micro$oft, which carries all the sh.t through its OSs... -- Denis A. Doroshenko [GPRS engineer] .-._|_ | [Omnitel Ltd., T.Sevcenkos st. 25, Vilnius, Lithuania] | | _ _ _ .| _ | [Phone: +370 9863486 E-mail: [EMAIL PROTECTED]] |_|| | || |||(/_|_ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] PL/java?
I keep hearing all this talk about Java being slow, and how compiled Java is nearly as slow as interpreted languages... If Java was _that_ slow, do you think it would be powering a majority of the Enterprise level sites out there? Java is really more than just hype. Surely it isn't nearly as fast as native optimized C/C++. But there are numerous advantages to the language. If you can afford to learn another language, and get some time to put it to practical use, I suggest that you take a closer look at Java... or IMHO, atleast don't knock it until you have substancial reasoning. -Kevin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Gowey, Geoffrey Sent: Saturday, August 25, 2001 5:09 PM To: 'Dr. Evil'; [EMAIL PROTECTED] Subject: RE: [GENERAL] PL/java? probably a bad idea. From what I've heard the speed of your java program is wholely dependent on the speed of your vm (and most aren't that quick). Although it would be nice to have just to say we have it and mysql doesn't (then again mysql doesn't have a whole lot of things that pgsql already has). Geoff -Original Message- From: Dr. Evil [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 25, 2001 7:38 PM To: [EMAIL PROTECTED] Subject: [GENERAL] PL/java? What do you think of having java as a procedural language available in PG? It seems like java has many advantages. I'm just wondering if people have thoughts or ideas on this, and if someone is actually working on it, that would be cool. ---(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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] PL/java?
-Original Message- From: Dr. Evil [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 25, 2001 7:38 PM To: [EMAIL PROTECTED] Subject: [GENERAL] PL/java? What do you think of having java as a procedural language available in PG? It seems like java has many advantages. I'm just wondering if people have thoughts or ideas on this, and if someone is actually working on it, that would be cool. Gowey, Geoffrey [EMAIL PROTECTED] wrote in message E15F4B031E17D5118B18009027F67927DAC0@SERVER">news:E15F4B031E17D5118B18009027F67927DAC0@SERVER... probably a bad idea. From what I've heard the speed of your java program is wholely dependent on the speed of your vm (and most aren't that quick). Although it would be nice to have just to say we have it and mysql doesn't (then again mysql doesn't have a whole lot of things that pgsql already has). Geoff This was a major issue in 1996. It's been solved for several years now, but the perception of Java having a speed problem remains. Java stored procedures are the #1 most-desired-by-me feature for PostgreSQL. Oracle and Sybase are examples of databases that have this feature already. (Strangely, Microsoft's database doesn't have it :-) Marshall Spight ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] PL/java?
On Thu, 30 Aug 2001, Marshall Spight wrote: This was a major issue in 1996. It's been solved for several years now, but the perception of Java having a speed problem remains. Java stored procedures are the #1 most-desired-by-me feature for PostgreSQL. Oracle and Sybase are examples of databases that have this feature already. (Strangely, Microsoft's database doesn't have it :-) Its not a perception. Java is still a dog. Again, see my mail message of few days ago regarding faking PL/java using pl/perl ;) -alex ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] PL/java?
On Mon, 27 Aug 2001, Tom Lane wrote: The latter is what I'm interested in, since \d doesn't invoke anything that I'd consider crash-prone. Could you submit a debugger backtrace from the crash? I should do that. But, since it's the back-end that's crashing, I'd need to find some way of getting a core dump. So far, it isn't producing any. I'll have to play with the environment to see why. Yes, I know, 6.* was not very careful about defending itself from tuples over 8K. But 7.0 is, which is why I don't think that the tuple length is relevant. I'd like to quit bandying accusations about and instead find out *exactly why* Postgres is crashing on you, so that we can either fix it or confirm that it's been fixed already. Yeah, I know. I was just trying to defend mysql. ^_^ We use both, and so far, it's been the smaller headache, so... I'll do what I can to get you a backtrace. The really strange thing is, one of our newwer databases has started hanging on vacuums. That's a 7.1.1, so the 8k thing shouldn't be any kind of issue in the slightest thanks to the new internal structures. But something is corrupt enough to break vaccum badly. That doesn't make me feel very good. The worst part is, while it's hung on the vacuum, idle connections just start piling up until we have to restart the DB. That's no good. -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. ThomasINN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830| | Email: [EMAIL PROTECTED]AIM : trifthen | | Web : hamster.lee.net | | | | Most of our lives are about proving something, either to | | ourselves or to someone else. | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] PL/java?
Shaun Thomas wrote: ... The really strange thing is, one of our newwer databases has started hanging on vacuums. That's a 7.1.1, so the 8k thing shouldn't be any kind of issue in the slightest thanks to the new internal structures. But something is corrupt enough to break vaccum badly. That doesn't make me feel very good. The worst part is, while it's hung on the vacuum, idle connections just start piling up until we have to restart the DB. That is probably an issue with one of your applications keeping an open transaction against the table vacuum is attempting to access: In Session #1: BEGIN; SELECT * FROM employees; In Session #2: VACUUM employees; VACUUM is waiting on Session #1 In Session #3: SELECT * FROM employees; --- Now waiting because of VACUUM In Session #1: END; You will see the Session #2 VACUUM complete and then the Session #3 SELECT complete. You've got some broken client app that needs to either COMMIT or ABORT. Hope that helps, Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] PL/java?
On 28 Aug 2001, Doug McNaught wrote: You obviously know what you're doing, but are you absolutely sure one of your clients isn't holding a transaction open? That'll hang vacuum every time... Yup. We wrote the client that is accessing the database. It's using PHP, and we don't even *use* transactions currently. But that isn't the problem. From what I gather so far, the server is under fairly high load (6 right now) so vacuuming the database (520MB in files, 5MB dump) takes a *long* time. While it's vacuuming, anything using that database just has to wait, and that's our problem. Actually, on a whim, I dumped that 520MB database to it's 5MB file, and reimported it into an entirely new DB. It was 14MB. We vacuum at least once an hour (we have a loader that runs every hour, it may run multiple concurrent insert scripts). We also use vacuum analyze. So, I really can't see a reason for it to balloon to that horridly expanded size. Maybe stale indexes? Aborted vacuums? What on earth would cause that? -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. ThomasINN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830| | Email: [EMAIL PROTECTED]AIM : trifthen | | Web : hamster.lee.net | | | | Most of our lives are about proving something, either to | | ourselves or to someone else. | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] PL/java?
Shaun Thomas [EMAIL PROTECTED] writes: Actually, on a whim, I dumped that 520MB database to it's 5MB file, and reimported it into an entirely new DB. It was 14MB. We vacuum at least once an hour (we have a loader that runs every hour, it may run multiple concurrent insert scripts). We also use vacuum analyze. So, I really can't see a reason for it to balloon to that horridly expanded size. Maybe stale indexes? Aborted vacuums? What on earth would cause that? VACUUM doesn't currently vacuum indexes. Yes, it's a serious wart. :( That's why the data file size declined so much (modulo WAL stuff). I suggest drop/recreate the indexes at intervals. Or try REINDEX, which may work better. -Doug -- Free Dmitry Sklyarov! http://www.freesklyarov.org/ We will return to our regularly scheduled signature shortly. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] PL/java?
On 28 Aug 2001, Doug McNaught wrote: Maybe stale indexes? Aborted vacuums? What on earth would cause that? VACUUM doesn't currently vacuum indexes. Yes, it's a serious wart. :( Ah, now that makes sense. It would also explain why our daily inserts of many thousands of rows on a fairly regular basis would slowly bloat the db. It would also explain why the old system, which didn't use indexes at all, didn't have this problem. It would also explain why the query optimizer picks crap plans, since the indexes are completely innaccurate. Hmm. That's more than a wart, that's nearly a show-stopping bug. I suggest drop/recreate the indexes at intervals. Or try REINDEX, which may work better. Reindex is really our only option. The database schema is complex enough that dropping and recreating the indexes is dangerous (esp. primary keys) and we also want to keep user databases from doing this - and we don't know the details of those DB's. Unfortunately, reindex can only be run while the DB is down. ::sigh:: So, looks like a cron job to run at 2am. # --- Pseudocode --- # Get list of DB's. Take backend down. For each DB REINDEX DATABASE DB done Put backend back up. print Damn Vacuum. # --- End Pseudocode --- # Ew -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. ThomasINN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830| | Email: [EMAIL PROTECTED]AIM : trifthen | | Web : hamster.lee.net | | | | Most of our lives are about proving something, either to | | ourselves or to someone else. | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] PL/java?
Yup. We wrote the client that is accessing the database. It's using PHP, and we don't even *use* transactions currently. But that isn't the problem. From what I gather so far, the server is under fairly high load (6 right now) so vacuuming the database (520MB in files, 5MB dump) takes a *long* time. While it's vacuuming, anything using that database just has to wait, and that's our problem. Well every query is in it's own transaction unless you explicitly say BEGIN and END -- so you technically are using transactions... I have a 14x larger (70 meg, dumped) database running on a dual PII400 that only takes 2 minutes or so to vacuum analyze (lots-o-indexes too), though I guess that's a long time in some settings, we only do it once day though.. Actually, on a whim, I dumped that 520MB database to it's 5MB file, and reimported it into an entirely new DB. It was 14MB. We vacuum at least once an hour (we have a loader that runs every hour, it may run multiple concurrent insert scripts). We also use vacuum analyze. So, I really can't see a reason for it to balloon to that horridly expanded size. Maybe stale indexes? Aborted vacuums? What on earth would cause that? I've read that you can take the size of the data out of the database, multiply it by 6 and you'll get the approximate size of the same data stored in the database... Obviously that's not working in your case.. Every UPDATE and DELETE leaves the tuple that was updated or deleted until vacuum is run but I don't see how that would happen on a fresh import into a newly created DB... -Mitch ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] PL/java?
On Mon, Aug 27, 2001 at 09:40:13AM -0400, Alex Pilosov wrote: For the people who really really want PL/java, you can fake it with untrusted pl/perl (in 7.2) and Inline::Java. Off topics -- I am very interested in this plperlu Can plperlu be used in triggers? Any idea how I can go about using it before 7.2 is released? Thanks ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
RE: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
My favorite part of the artical was way way down at the end, where it briefly lists a few areas where postgres is still superior, minor little details such as full joins, sub-selects, views, unions, triggers, constraints, cursors... silly stuff like that :-) Glen ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] PL/java?
On 25 Aug 2001, Doug McNaught wrote: Can someone explain why the addition of a stored procedural language for MySQL made it as a Slashdot headline? Probably because /. uses MySQL (poor benighted fools ;) Back when Slashdot was designed, Postgres was crap. We have old versions we're still getting rid of, and they're the biggest headache in the world. I've actually used \d and the back-end crashed. Usually this happens when the database has handled around 15k queries in one session, or someone, somewhere, even looks in the direction of a row that is anywhere near the 8k limit. It's very simple. Anything before postgres 7.1 was complete, utter crap. Slashdot was around way before 7.1, hence mysql. Personally, I laud their decision. I mean, I've never had show tables crash a mysql database, yet \d (or even a single-table, no where clause select) can crash the back end of postgres 7.0.3. We can't even do bulk inserts on these tables (20k rows) because the back end inexplicably dies before it finishes. I'm talking about insert statements, not postgres proprietary COPY. -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. ThomasINN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830| | Email: [EMAIL PROTECTED]AIM : trifthen | | Web : hamster.lee.net | | | | Most of our lives are about proving something, either to | | ourselves or to someone else. | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
= In MySQL you have to repair your tables manually if corruption occurs. PostgreSQL is coded so that corruption cannot occur. Unless you're running pre-7.1, in which doing any of the following may corrupt an entire database so badly that pg_dumpall crashes on it. * Table A. Create mirror table B. Insert into B. Drop A. Rename B to A. Watch backend crash randomly, corrupting said table to unrecognizable form - hence corrupting entire database. This may only happen once every 1000 times the process is repeated, but *will* occur eventually. This happened more in 6.5. * Select, insert, update, whatever. Eventually, postgrees will report that the back end has exited unexpectedly. This is easier to repeat on an installation serving many simultaneous connections, especially if any database has been affected by: * Inserting any row with a total column length of 8k or higher, minus row/column overhead. For even more fun, insert a row of arbitrary length, or use multiple text columns. * Selecting, updating, or even remotely touching any table which has an example of the above. Yes, this means that you can't even delete the offending row, or pg_dump the database to remove it manually. What about pg_dump, you say? Sure, that'll work. Get the tables that aren't corrupted, like you know which ones they are. Then all you have to do is not give a rat's ass about the data in the table that *is* corrupted. Sounds easy, right? All of this vanished like smoke when 7.1 came out. In my opinion, 7.1 is the first real release of postgres, and hence Mysql is fully justified in most of its accusations/comparisons. Until 7.1, postgres didn't have a snowball's chance in hell at beating mysql on the stability front, now the odds are a little more even. Either way, don't dare sit there and tell me postgres doesn't corrupt tables. I would actually prefer a utility to integrity check/repair a corrupted table into something that the database could read, rather than give the data up for a loss and run for our backups, as we have been doing. -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. ThomasINN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830| | Email: [EMAIL PROTECTED]AIM : trifthen | | Web : hamster.lee.net | | | | Most of our lives are about proving something, either to | | ourselves or to someone else. | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
WAL and Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
You guys shouldn't even be worrying about this. Five years from now, MySQL will be a much more mature product, but the way I see it now is this: MySQL: Great for message boards (Slashdot), information retrieval (an on-line phone directory that's mostly static), or other lightweight applications. PG7.1: Great for doing more commercial type things: inventories, accounting, and business in general, but it does lack some of the high-end DB features, particularly replication and clustering, and also some performance optimizations, which make it not quite in the big-leagues yet. Oracle: Great for everything beyond PG7.1. MS-SQL: Use this one if you desperately need Western currency and want to lose some plutonium! PG7.2: It finally has replication! This makes it a strong competitor to Oracle for most applications. Why is replication so important? If the data you are dealing with are valuable, you simply cannot trust them to one machine. Machines catch on fire, buildings burn down, earthquakes happen, lightning strikes. A disaster can happen any time, anywhere. The only solution to this is replication. Until PG has it, it can't be trusted with really valuable data. One thing which I would like to see in addition to replication is an enhanced WAL mechanism. Right now WAL only writes to a log file. That's fine, but I can see two other things that WAL could do very easily, which would be great for financial users, or others who deal with valuable data: One is sending the tuple, as a string, off to another server somewhere to be logged, perhaps in another DB of some kind. That way, when Server #1 gets struck by lightning, no problem, not a single transaction has been lost. This wouldn't take any major mods to the WAL system; if someone would tell me where to look in the code, I'll do it myself. The second WAL change would be to allow WAL to send output to a plain old dot matrix printer. Yes, it's a primitive thing to do, but again, if you are dealing with financial transactions, sometimes it's a wonderful thing to be able to have them in a human-readable read-only format. No amount of elite hacking can undo something which has been printed. This technique, as primitive as it sounds, is used all over the place. Ever notice that when you put your ATM card in the machine, you often hear a printer going? Everything is logged the old-fashioned way. Again, if someone will point me to the place in the WAL code where it has the tuple and it wants to write it out, I'll make these mods myself. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
Peter Eisentraut [EMAIL PROTECTED] writes: Justin Clift writes: If anyone else can see things blatantly wrong on that page, email me about them and I'll ask Monty (the MySQL guy) to please change/remove/fix them. http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html Many of these advantages can easily interpreted as disadvantages. For example: * MySQL has more API to other languages and is supported by more programs than PostgreSQL. See section D Contributed Programs. = MySQL has 6 Perl modules, 5 ODBC drivers, and 4 C++ interfaces. PostgreSQL concentrates its efforts on making one driver work best for all users. For interfaces, it's best to have only one, and a good one (like one DBD module for perl, one JDBC interface for Java, one python module implementing the Python DB API (there are several Pg ones available here)). But this didn't just focus on APIs. * There are far moore books in print on MySQL than on PostgreSQL. O'Reilly, Sams, Que, and New Riders are all major publishers with books about MySQL. = MySQL is so hard to understand and poorly documented, a plethora of books had to come out before anyone could use it. That is a ridiculous claim. More documentation is good - like how to apply the different scenarios and by different authors. From Foo in 24 hours to Data mining with bar. * All MySQL features is also documented in the MySQL on-line manual because when a feature is implemented, the MySQL developers are required to document it before it's included in the source. = blah... :-) The MySQL documentation is actually rather nice (not saying that the PostgreSQL isn't). * MySQL has support for tables without transactions for applications that need all speed they can get. = MySQL is not a fully transactional database system. It defaults to this as well, AFAIR. * MySQL has internal support for text search. See section 6.8 MySQL Full-text Search. = PostgreSQL has a number of different full text search solutions available, or users can plug in their own. Weren't you the one preaching the wonders of one way to do it (API-wise) above? * You can access many databases from the same connection (depending of course on your privileges). = PostgreSQL does not allow you to access more than one database per connection. This makes the system much safer and allows for more robust design. Sometimes, you'd like to anyway ;) The person doing the bugzilla port would even like to have multi-DB operations (and split tables, with parts of the query running on each one). = PostgreSQL is coded from the start with multi-processing while MySQL uses threads. Threads have historically led to much more bug-prone programs and are poorly supported on many operating systems. If one thread crashes your whole server goes down. * MySQL has a much more sophisticated privilege system than PostgreSQL. = MySQL has a much more complicated privilege system than PostgreSQL. There is a difference between what must be done and what can be done. E.g. you can use Emacs quite comofortably as a very powerful editor without knowing much lisp. You can do anything you want if you need to. * MySQL employs the table handler concept and is the only relational database we know of built around this concept. = MySQL employs a table handler concept, which makes your code much less SQL compliant and makes MySQL harder to learn. Do you have to use it, or is it something you can choose to take advantage of? * Tools to repair and optimize MyISAM tables (the most common MySQL table type). = In MySQL you have to repair your tables manually if corruption occurs. PostgreSQL is coded so that corruption cannot occur. You sound like H.R. That's not a compliment. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
Me writes: http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html Many of these advantages can easily interpreted as disadvantages. For example: I hope people aren't taking that feature comparison page as seriously as they took my parody of it. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
On Sun, 26 Aug 2001, Peter Eisentraut wrote: Many of these advantages can easily interpreted as disadvantages. For example: Have you ever considered a career in marketting? = In MySQL you have to repair your tables manually if corruption occurs. PostgreSQL is coded so that corruption cannot occur. Ho ho. This one is my favorite. -sam ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
Hi Sean, We can always ask them to change things. The thing which strike me as wrong the most is the stability issue with PostgreSQL. I've only very rarely heard reports by anyone saying MySQL was more stable than PostgreSQL for them. Most of the rest I think can be justified in one way or another. If anyone else can see things blatantly wrong on that page, email me about them and I'll ask Monty (the MySQL guy) to please change/remove/fix them. :-) Regards and best wishes, Justin Clift Sean Chittenden wrote: Has anyone seen this page on Mysql.org comparing PostgreSQL to MySQL: http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html Yeah, I've had a few developers show it to me... the best part of this is though, when I tried to post a comment, I got a MySQL database error. ::grin:: At anyrate, it looks like a load of FUD from a bad marketing department (at least Microsoft lies well). -sc -- Sean Chittenden Part 1.2Type: application/pgp-signature ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
RE: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
We can always ask them to change things. The thing which strike me as wrong the most is the stability issue with PostgreSQL. I've only very rarely heard reports by anyone saying MySQL was more stable than PostgreSQL for them. Yeah, saying mysql is more stable than postgres is a complete joke from my own experiences and those around me. Also, I think people move from mysql to postgres, rarely the other way round.. - Andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
Sean Chittenden wrote: Has anyone seen this page on Mysql.org comparing PostgreSQL to MySQL: http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html Yeah, I've had a few developers show it to me... the best part of this is though, when I tried to post a comment, I got a MySQL database error. ::grin:: At anyrate, it looks like a load of FUD from a bad marketing department (at least Microsoft lies well). -sc One might also add as a 'con' for mysql...spelling. As horribly frequent the spelling errors are on this page, one might reasonable assume that you could... selected * frm tabloid wear valued be 'huh?'; -d -- : I may have the information you need and I may choose only HTML. It's up to you. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
