6 ms·

> And don't take me wrong, I'll take MySQL instead of PostgreSQL for simple and medium projects. Why? I can't see one feature that MySQL delivers better than P

> And don't take me wrong, I'll take MySQL instead of PostgreSQL for simple and medium projects. Why? I can't see one feature that MySQL delivers better than Pgsql...

raverbashing 13y ago
It's really funny when I get asked that question, really: PostgreSQL is a pain to setup, the SQL parser is very finnicky and for the past times I spent too much time trying to work around every idiosyncrasy of Postgres when I could have a similar MySQL instance running in a shorter time So, MySQL doesn't waste my time with stupid crap. Now please call me ignorant and downvote me since PostgreSQL fanboys can't take a critique and think their loved database is perfect.
- pnathan 13y ago
  Honestly, this is not my experience at all, and I'm not a DBA. I install postgres, I fiddle with setting up a user & pg_hba.conf to allow connections, and after that it's basically game on.
- Xylakant 13y ago
  Not calling you ignorant, but for workloads that a simple, untuned mysql installation is sufficient you can just build yourself a simple, default postgresql installation. Use chef, puppet, terraform,... to make that repeatable and the setup pain goes away.
  - raverbashing 13y ago
    True, Chef and Puppet kind of take the pain away between different linux distributions (which is good). But this would be aiming at a deployment. However, one common use case (for me) is having to have a one-off install, which unfortunately kind of prevents that. If my job needed frequently installs of DBs I would have probably gone this way, but it isn't, so today it's PostgreSQL 9.1 on Mac OS, tomorrow (more likely, a year or two from now) it's MySQL on Fedora, etc
    - Xylakant 13y ago
      Chef and Puppet can deploy just fine into a development machine - either a VM (i'd recommend this) or even on your host machine. I can't imagine any workload that's simple enough to be handled by a vanilla, untuned mysql instance and at the same time not simple enough to be handled by a scripted postgres installation. Things get different once you're getting to more complex workloads, but the effort of tuning a mysql instance to handle those is in the same ballpark as the effort of tuning a postgres instance.
- Roboprog 13y ago
  The odd thing is that my experience has been the opposite. Perhaps only because I started using PostgreSQL earlier, but nonetheless. My experience has been running on Slackware/RedHat/Ubuntu, though, and never on any Windows version, if that matters. I really like how all values in the SQL in PostgreSQL can be replaced with arbitrary expressions, including stored functions. YMMV.
  - raverbashing 13y ago
    PostgreSQL is not user friendly. What is an hba file? How am I supposed to know what it does? PostgreSQL has a "createuser" command. Great, but how am I supposed to know this is a PSQL command? (not to mention potential collision with other filenames) RTFM? This is an acceptable answer, but it disregards completely the user experience. MySQL is more intuitive. Authentication? User/password. None of this "ident" or "trust" (really?) schemes. Yes, pg_hba is more flexible, but if you have only one DB user... Yes, it's convenient to have a local "trust" connection. Also a little bit more insecure as well. And there are convenient mysql* commands, you can tell they are mysql commands.
    - sergiosgc 13y ago
      An hba file is one of the configuration files. The converse question would be: What is a my.cnf file? How am I supposed to know what it does? The answer is the same for both: RTFM The CREATE USER issue is just bad faith on your part. It is a de-facto standard, used by Oracle, Transact-SQL and ironically MySQL. In the end, your complain boils down to: 1. Having to edit pg_hba replacing "ident" with "password" 2. Unfamiliarity with pgsql opposed to familiarity with mysql A developer that chooses tools primarily based on familiarity is on the slippery slope to dinosaur land. Not that it's bad -- Cobol development still pays well to this day.
      - raverbashing 13y ago
        I'm not talking about "CREATE USER", I'm talking about /usr/sbin/createuser (or whatever it is installed in your system) "A developer that chooses tools primarily based on familiarity " Yes, let me waste time to learn how to use the latest fad on HN, sure (not talking about PostgreSQL here) And PostgreSQL is made of unicorn blood and my projects will be 200% better if I use it instead of MySQL, sure. It's a DB. There's a narrow range where it would make a difference to use it instead of scaling to more servers, for example. And you can "always" convert later. (Unless you're FB apparently)
- FraaJad 13y ago
  > SQL parser is very finnicky In what way is it finicky?
  - raverbashing 13y ago
    http://www.merriam-webster.com/dictionary/finnicky http://www.merriam-webster.com/dictionary/finnicky For example, MySQL accepts both ' and " as string delimiters. It's very fun trying to get around PGSQL not understanding what you want to do while MySQL understands. It doesn't require ';' to mark the end of a command
    - dragonwriter 13y ago
      > For example, MySQL accepts both ' and " as string delimiters. That is, in its default mode, MYSQL does not accept ANSI-standard quoted identifiers (supporting only non-standard use of backquotes for quoted identifiers), and instead treats double quotes as equivalent to single quotes for strings. (Of course, MYSQL has a non-default option to support the standard.) PostgreSQL, OTOH, supports the standard out of the box, and treates double quoted material as quoted identifiers. Neither behavior is more finnicky, one is just standards-compliant. > It's very fun trying to get around PGSQL not understanding what you want to do while MySQL understands This would appear to only be an issue if your only RDBMS experience is with MySQL and you are adapted to its quirks, since if you have experience with other DBs which adhere to the ANSI standards for basic behavior, MySQL will, by default, be more likely to not understand what you mean than PostgreSQL.
- sergiosgc 13y ago
  PostgreSQL setup is as easy as yum install postgresql. You may have to tweak pg_hba.conf to get password authentication in some distros, but this is it setup-wise. As for the parser being finnicky, that is a feature. Hint: an empty string in a timestamp does not mean midnight 1/1/1970. This is one area where mysql did more harm than good: getting developers hooked in sloppy SQL.
- dragonwriter 13y ago
  > PostgreSQL is a pain to setup I've installed it on Linux and Windows and, no, its not. Its pretty much the same work as MySQL to setup, except the install usually wants information to create or use a system user for the DB server in the install, which is a trivial amount of extra work. I understand this used to be an issue many years ago (IIRC, most of the streamlining of the setup happened in the first couple of major 8.x releases, in 2005-2006, about the same time as official native Windows support was added.) > the SQL parser is very finnicky How so?
ddorian43 13y ago
upserts?

> And don't take me wrong, I'll take MySQL instead of PostgreSQL for simple and medium projects. Why? I can't see one feature that MySQL delivers better than Pgsql...

raverbashing 13y ago

It's really funny when I get asked that question, really: PostgreSQL is a pain to setup, the SQL parser is very finnicky and for the past times I spent too much time trying to work around every idiosyncrasy of Postgres when I could have a similar MySQL instance running in a shorter time So, MySQL doesn't waste my time with stupid crap. Now please call me ignorant and downvote me since PostgreSQL fanboys can't take a critique and think their loved database is perfect.

pnathan 13y ago
Honestly, this is not my experience at all, and I'm not a DBA. I install postgres, I fiddle with setting up a user & pg_hba.conf to allow connections, and after that it's basically game on.
Xylakant 13y ago
Not calling you ignorant, but for workloads that a simple, untuned mysql installation is sufficient you can just build yourself a simple, default postgresql installation. Use chef, puppet, terraform,... to make that repeatable and the setup pain goes away.
- raverbashing 13y ago
  True, Chef and Puppet kind of take the pain away between different linux distributions (which is good). But this would be aiming at a deployment. However, one common use case (for me) is having to have a one-off install, which unfortunately kind of prevents that. If my job needed frequently installs of DBs I would have probably gone this way, but it isn't, so today it's PostgreSQL 9.1 on Mac OS, tomorrow (more likely, a year or two from now) it's MySQL on Fedora, etc
  - Xylakant 13y ago
    Chef and Puppet can deploy just fine into a development machine - either a VM (i'd recommend this) or even on your host machine. I can't imagine any workload that's simple enough to be handled by a vanilla, untuned mysql instance and at the same time not simple enough to be handled by a scripted postgres installation. Things get different once you're getting to more complex workloads, but the effort of tuning a mysql instance to handle those is in the same ballpark as the effort of tuning a postgres instance.
Roboprog 13y ago
The odd thing is that my experience has been the opposite. Perhaps only because I started using PostgreSQL earlier, but nonetheless. My experience has been running on Slackware/RedHat/Ubuntu, though, and never on any Windows version, if that matters. I really like how all values in the SQL in PostgreSQL can be replaced with arbitrary expressions, including stored functions. YMMV.
- raverbashing 13y ago
  PostgreSQL is not user friendly. What is an hba file? How am I supposed to know what it does? PostgreSQL has a "createuser" command. Great, but how am I supposed to know this is a PSQL command? (not to mention potential collision with other filenames) RTFM? This is an acceptable answer, but it disregards completely the user experience. MySQL is more intuitive. Authentication? User/password. None of this "ident" or "trust" (really?) schemes. Yes, pg_hba is more flexible, but if you have only one DB user... Yes, it's convenient to have a local "trust" connection. Also a little bit more insecure as well. And there are convenient mysql* commands, you can tell they are mysql commands.
  - sergiosgc 13y ago
    An hba file is one of the configuration files. The converse question would be: What is a my.cnf file? How am I supposed to know what it does? The answer is the same for both: RTFM The CREATE USER issue is just bad faith on your part. It is a de-facto standard, used by Oracle, Transact-SQL and ironically MySQL. In the end, your complain boils down to: 1. Having to edit pg_hba replacing "ident" with "password" 2. Unfamiliarity with pgsql opposed to familiarity with mysql A developer that chooses tools primarily based on familiarity is on the slippery slope to dinosaur land. Not that it's bad -- Cobol development still pays well to this day.
    - raverbashing 13y ago
      I'm not talking about "CREATE USER", I'm talking about /usr/sbin/createuser (or whatever it is installed in your system) "A developer that chooses tools primarily based on familiarity " Yes, let me waste time to learn how to use the latest fad on HN, sure (not talking about PostgreSQL here) And PostgreSQL is made of unicorn blood and my projects will be 200% better if I use it instead of MySQL, sure. It's a DB. There's a narrow range where it would make a difference to use it instead of scaling to more servers, for example. And you can "always" convert later. (Unless you're FB apparently)
FraaJad 13y ago
> SQL parser is very finnicky In what way is it finicky?
- raverbashing 13y ago
  http://www.merriam-webster.com/dictionary/finnicky http://www.merriam-webster.com/dictionary/finnicky For example, MySQL accepts both ' and " as string delimiters. It's very fun trying to get around PGSQL not understanding what you want to do while MySQL understands. It doesn't require ';' to mark the end of a command
  - dragonwriter 13y ago
    > For example, MySQL accepts both ' and " as string delimiters. That is, in its default mode, MYSQL does not accept ANSI-standard quoted identifiers (supporting only non-standard use of backquotes for quoted identifiers), and instead treats double quotes as equivalent to single quotes for strings. (Of course, MYSQL has a non-default option to support the standard.) PostgreSQL, OTOH, supports the standard out of the box, and treates double quoted material as quoted identifiers. Neither behavior is more finnicky, one is just standards-compliant. > It's very fun trying to get around PGSQL not understanding what you want to do while MySQL understands This would appear to only be an issue if your only RDBMS experience is with MySQL and you are adapted to its quirks, since if you have experience with other DBs which adhere to the ANSI standards for basic behavior, MySQL will, by default, be more likely to not understand what you mean than PostgreSQL.
sergiosgc 13y ago
PostgreSQL setup is as easy as yum install postgresql. You may have to tweak pg_hba.conf to get password authentication in some distros, but this is it setup-wise. As for the parser being finnicky, that is a feature. Hint: an empty string in a timestamp does not mean midnight 1/1/1970. This is one area where mysql did more harm than good: getting developers hooked in sloppy SQL.
dragonwriter 13y ago
> PostgreSQL is a pain to setup I've installed it on Linux and Windows and, no, its not. Its pretty much the same work as MySQL to setup, except the install usually wants information to create or use a system user for the DB server in the install, which is a trivial amount of extra work. I understand this used to be an issue many years ago (IIRC, most of the streamlining of the setup happened in the first couple of major 8.x releases, in 2005-2006, about the same time as official native Windows support was added.) > the SQL parser is very finnicky How so?

ddorian43 13y ago

upserts?