Re: Postgresql -- initial impressions and comments
От | Dave Best |
---|---|
Тема | Re: Postgresql -- initial impressions and comments |
Дата | |
Msg-id | 002301c29b4e$71f76bf0$010000ac@prison обсуждение исходный текст |
Ответ на | Postgresql -- initial impressions and comments ("j.random.programmer" <javadesigner@yahoo.com>) |
Список | pgsql-general |
I'm new to the community as well, a couple of responses to your points and my impressions below. ----- Original Message ----- From: "j.random.programmer" <javadesigner@yahoo.com> To: <pgsql-general@postgresql.org> Sent: Monday, December 02, 2002 9:44 PM Subject: [GENERAL] Postgresql -- initial impressions and comments > 1) > Running postgres as non-root is understandable but > should not be _mandated_ (for totally private > networks, > it's overkill). Trust the user... Never, ever run anything under root if at all possible. Its just baddddd..... Trust the user? Your joking right? :) I've been around too many Lusers (as my friend would say) to trust any of em. > > 3) The documentation needs to be radically improved. > The mysql docs are much more comprehensive. Postgres > wins hands down in the database internals > documentation > (mysql doesn't have any) but loses in the userland > documentation. Recently i've evaluated both mysql and postgresql for a project myself and a few friends are working on. There are areas in both sets of documentation that could use a little work but in general I find both adequate. Actually the only thing that puts mysql's on the same level as postgres's, is the user comments. > 4) The auto-increment ("serial") fields are very > badly documented. > > Normally, I want to say something like: > > INSERT into foo values (null, 'a', 'b',...) > > INSERT into foo > (field_a, field_b,...) values ('a', 'b', ...) > The first one is bad form.. If your schema ever changes your application will break but i'm sure you've gotten many responses on this. I setup 'serial' columns in both mysql and postgres with ease, didn't see any issues with the docs for either. With our project we decided to go with Postgres because it has an extensive feature set. L8r all.
В списке pgsql-general по дате отправления: