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:drevil@sidereal.kz]
Sent: Saturday, August 25, 2001 7:38 PM
To: pgsql-general@postgresql.org
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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

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

"Gowey, Geoffrey" <ggowey@rxhope.com> writes:

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).

Well, compiled Java code can't be that much slower than PL/pgSQL code
or TCL. both of which work fine for lots of people...

I've though about doing this. It's definitely doable, but here are
some gotchas:

* The JVM is multithreaded, while backends are single-threaded. This
could open up a big can of worms if you're not careful. On
platforms with different libc's for threaded/nonthreaded code, you'd
have to get the linking right.

* In order to be useful, you'd need to write a JNI wrapper for the SPI
libraries. Again, threading issues may apply.

It's an interesting project, but not one I've had time to look at yet.

-Doug
--
Free Dmitry Sklyarov!
http://www.freesklyarov.org/

We will return to our regularly scheduled signature shortly.

See the TODO list under Java. There are some emails discussing the
issues:

http://candle.pha.pa.us/cgi-bin/pgtodo?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.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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).

Can someone explain why the addition of a stored procedural language for
MySQL made it as a Slashdot headline? Do our new features make it
there?

http://slashdot.org/article.pl?sid=01/08/24/1253228&amp;mode=nested

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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).

Has anyone seen this page on Mysql.org comparing PostgreSQL to MySQL:

http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

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 ;)

-Doug
--
Free Dmitry Sklyarov!
http://www.freesklyarov.org/

We will return to our regularly scheduled signature shortly.

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

----- Original Message -----
From: "Sean Chittenden" <sean-pgsql-general@chittenden.org>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "Gowey, Geoffrey" <ggowey@rxhope.com>; "'Dr. Evil'"
<drevil@sidereal.kz>; <pgsql-general@postgresql.org>
Sent: Saturday, August 25, 2001 11:48 PM
Subject: Re: MySQL's (false?) claims... (was: 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).

PG has no competition from MySQL. MySQL finally got a procedural
language, but it's perl! perl is in many ways a terrible PL.
Basically, if you are using a database for any kind of real stuff
where data integrity and reliability are important, you need a
strongly-typed language. PL/pgsql is actually a greal language for
this. Far better than perl.

Anyway... yeah, I have heard that a lot of java vms are not fast, but
a lot of the time fast isn't as important as solid and correct, and
java lends itself to solid, correct programming better than most other
languages.

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

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

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.

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.

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.

* 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.

* 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... :-)

* MySQL has support for tables without transactions for applications that
need all speed they can get.

=> MySQL is not a fully transactional database system.

* MySQL has support for 3 different table handles that support
transactions

=> In PostgreSQL you don't need to think about which table type to choose
because one works for all.

* 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.

* 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.

* MySQL is coded from the start with multi-threading while PostgreSQL uses
processes.

=> 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.

* 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.

* 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.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

At 03:21 PM 8/26/01 +0200, Peter Eisentraut wrote:

* 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.

I disagree. MySQL was quite easy to understand (furthermore it was limited
in what it could do :) ). And it's well documented. The limitations were
documented too - that part I liked very much. As for the justifications for
their limitations, some valid and the rest not that important to me -
ignorable.

I found postgresql harder to understand when I first tried it (Postgres95).
And performance was terrible then, so I had to revert to MySQL.

Then there were these adhoc pgsql commands you run from the command shell
which didn't work for me (createdb etc). I had turned on access controls in
pg_hba which broke most of the command shell scripts which assumed no
access controls, and the PGSQL documentation assumed that most people would
use the command shell scripts/programs...

* 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.

Yah, I hope you realised you used a similar argument against MySQL for
their many APIs :).

* 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.

How does that makes things safer etc etc? I believe that this is a genuine
limitation.

I hope the developers are honest why this limitation exists. There are
probably valid and good reasons for this limitation but I don't think
"safer and more robust" is a good one. If it really is, then it reduces my
confidence level in Postgresql's access control design/internals.

* MySQL has a much more sophisticated privilege system than PostgreSQL.

=> MySQL has a much more complicated privilege system than PostgreSQL.

Just different to me.

* 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.

I sure hope so.

But I also hope that people look at things objectively and not blind
themselves in defense of what they hold dear.

Taking a long view of things, MySQL is likely to have some design and usage
issues with the multiple ways of handling what they call transactions. They
may have to do some pruning soon and leave only the good branches.

Postgresql is better for what I currently need to do. I'm glad it has
improved a lot.

Cheerio,
Link.

Lincoln Yeoh <lyeoh@pop.jaring.my> writes:

=> 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.

How does that makes things safer etc etc? I believe that this is a genuine
limitation.

It's unlikely that the "one DB per connection" limitation will ever
change. What is likely to happen (for 7.3, with any luck) is that we
will implement SQL92-compatible schema naming within the traditional
Postgres notion of a database. More than likely, most installations
will then migrate to keeping all their stuff in multiple schemas within
one big database, and the issue will cease to be a problem in practice
even though the technical limitation is still there.

I have no doubt that MySQL's comparison page will keep pointing to this
issue as a fatal limitation of PG long after it ceases to be a problem,
however ;-)

* 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.

I sure hope so.

A more accurate way of stating this is "we prefer to spend our
development time on eliminating bugs, not on devising tools to clean up
after bugs".

regards, tom lane

Peter Eisentraut <peter_e@gmx.net> 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.