Re: need for concrete info - Mailing list pgsql-general

How about the inconsistency on MySQL (not only with NULL values). Try
inserting a 64 bit integer in a 32 bit field and check the result. It's not a
bug, it's "gotcha"!!

By the way, we are building an aplication with PHP and PostgreSQL, and I can
tell you that we would have had real pains if we were to use the other DB.
Mainly we are making lots of functions in plpgsql, and loading some triggers,
things very usefull, and missing in MySQL.

El Dom 12 Oct 2003 15:12, Keary Suska escribió:
> on 10/11/03 6:48 PM, gearond@fireserve.net purportedly said:
> > Well, now I am writing a proposal, which among many other points,
> > proposes to switch from the current hosting site of a non profit to a
> > slightly more expensive one running PostgreSQL, (where I have some other
> > projects.) I want to use as my main argument, the fact (at this time,
> > only from my previous usage), that MySQL really doesn't have foreign
> > keys or record locking, and Postgres does.
> >
> > I will be trusted to say this, and I don't have to reprint the manuals
> > from each DB in my proposal, or maybe I will. But anyway, I'm still
> > correct with today's MySQL vs. PostgreSQL, right? I *really* want to use
> > PostgreSQL for this project and not MySQL as I want to avoid growing
> > pains trying to get MySQL to do the job of a bigger DB down the road.
>
> MySQL is closing the gap, so many of its drawbacks are no longer the case,
> and you have to look a little harder for its weaknesses, but they are
> there. Fortunately, MySQL spells many of them out for you:
> http://www.mysql.com/documentation/mysql/bychapter/manual_Introduction.html
># Roadmap
>
> You will see that MySQL has planned to implement features that Postgres has
> had for a long time (in development terms). In Postgres, they are tried and
> true. In MySQL, it will take a while, and do you want your application to
> help them beta test? You may also want to consider that their
> implementation schedule may not correspond with yours.
>
> Even if one could argue that the missing features are unnecessary for your
> application, there is one huge problem (in my mind) that MySQL continues to
> have, namely it does not honor NOT NULL constraints. Granted, you can
> enforce this by recompiling with a specific option, but if you currently do
> not have any control over the compilation or configuration of MySQL you are
> stuck. Even if you can get this option, there are issues with multiple
> inserts arising out of a single statement, but that would imply that their
> transaction handling mechanism is not robust or it wouldn't be an issue.
>
> I would add that I am not a MySQL basher--I have used MySQL in amhy
> instances and it performs perfectly well in those cases. I simply believe
> (with justification) that Postgres is a better product, especially for
> larger and more complicated applications.
>
> Best,
>
> Keary Suska
> Esoteritech, Inc.
> "Leveraging Open Source for a better Internet"
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faqs/FAQ.html

--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués                  |        mmarques@unl.edu.ar
Programador, Administrador, DBA |       Centro de Telemática
                       Universidad Nacional
                            del Litoral
-----------------------------------------------------------------