Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I frequently have this conversation with Pg boosters who just won't recognize how annoying the initial setup for Pg is vs. the setup for MySQL. It's a fine database, and the auth system is powerful, but it's pretty obvious why newbies find MySQL easier to get going with.
    • I agree that installation is one of PG's weak areas, and I think part of the reason here is the way it's packaged on many distros. On Gentoo Linux, I can run 'emerge postgresql', followed by 'ebuild postgresql-8.1.3.ebuild config' and it takes care of creating a postgres user, creating a postgres database, and initializing the database. Doing this process manually (which is the case for many distributions) is tedious and probably turns off some users. If you have a reasonable sized database you'll also n

    • I've heard a lot of people say that Pg is hard to set up, and I just don't get it. I've used the Debian package install and the RPM package on RedHat and in both cases, it was just a question of "start server, create user, create database". Piece of cake.

      -Dom

      • The details of "create user, create database" are more complex than they are for MySQL. As Phred pointed out, he has a script to do it on Gentoo. The last Red Hat RPM of it that I tried required me to dig up some RPM-specific docs and edit a text file.
  • Your experiences I find astonishing. As a PostgreSQL user going back some 5 years, and recently asked to port my company's application to MySQL, I find MySQL to be unbelievably opaque. Funnily, I could mirror your complaints almost exactly:
    • Why is MySQL so hard to set up? Admittedly, I'm compiling from source in our environment, but PostgreSQL just compiles and installs. MySQL takes 3 times as long to compile, and installs a load of crap like tests that I'm not interested in, even when using the clie
    • MySQL is WAY easier to install - configure, make, make install - no creating and su'ing to a special user to create the databases.

      "Why is the command line interface so appalingly bad? The help is non-existent on every instance I've connected to. psql at least gives you \h."

      myql allows you to switch, and show databases, list and describe tables and best of all quit is quit and help is help. Table names and fields are tab completed. Postgresql is grumpy and unhelpful compared. The source command allows you to
      --

      @JAPH = qw(Hacker Perl Another Just);
      print reverse @JAPH;
      • You can solve the pg_dump issue by grabbing the pg_dump from any 8.1.x version. It's been refactored to address the issue of not working between different versions.

        Slony is actually a robust replication mechanism for what it's worth. It doesn't handle schema updates all that well, but I don't think many replication systems do handle that well.

        There is at least one full text indexing system in the contrib tree with the source.

      • "myql allows you to switch, and show databases, list and describe tables and best of all quit is quit and help is help."

        Just like psql, apart from quit/help.

        "Table names and fields are tab completed."

        Maybe in your version. For me, psql completes, mysql doesn't. And it gets ^W wrong to add insult to injury.

        "The source command allows you to run sql scripts without exiting and piping."

        In psql it's spelled \i. Try \? for some help on the psql commands.

        "The SQL Prompt is far easier and more powerf

        • he last time I looked at PostgreSQL, I liked what I saw but the lack of reliable out-of-the-box replication was a showstopper. I was quite surprised that PostgreSQL was lagging behind MySQL & Oracle in that area. PostgreSQL for me therefore is fine for simple apps on a single database host, but once you move into something a little more advanced with multiple redundant database hosts sitting behind a load balancer, replication is a must have feature.

          I just had a quick peek at the online documentation
        • I have used pgAdmin on other people's machines, it's slower, ugly and contains less features than the equivilent tools for Oracle (Toad/Tora), MySQL (mysql-query-browser, mysq-admin) and SQL Server. PGaccess runs but lacks most of the features I'd want.

          Trying Squirrel, I found that it can't find the jdbc classes for anything and is slow, ugly and clunky - but thats Java's fault rather than Postgres :)
          --

          @JAPH = qw(Hacker Perl Another Just);
          print reverse @JAPH;
    • I forgot my favourite bit of MySQL irritation: DBD::mysql doesn't support UTF-8 [mysql.com]. How long is it since Perl 5.6 came out now?

      -Dom

  • In general, stuff like that is kind of dangerous. MySQL allows you to use wildcards in several places in grants, and (for some of them) instead of expanding the wildcards at grant time it does so at query time. New users can be created with default permissions that let them access _way_ more stuff then they should. If/as you get more into PostgreSQL you'll see that it likes implicit actions much less then MySQL. Not as good for a joe-user, but if I was running an important database (which is what Postgr
  • But seriously...

    While I suspect you missed a couple of simple things, you're mostly right (especially for pre 8.0)

    I remember starting with MySQL back around 2000 and it was quite easy to set up.

    Postgres still remains harder, especially WRT the whole pg_hba.conf or whatever that bloody file is.

    I'm sure it's more secure or something, but it is still annoying.

    The more important underlying issue for me though is I'm not and never wish to be a sysadmin. Installation of any database (dear god Oracle *sob*) I just
    • Actually I haven't found MySQL hurts you on a day to day basis and neither have the guys at google, who looked at porting to postgres and decided (wisely) IMHO to stick with mySQL.

      I've found Postgres much more painful, and not just for setting up - I have to write my own bloody cast functions to convert boolean to int, I have dozens of small little queries utilising the ease of MySQL in the application I'm porting and find that each one requires a great deal of mucking about to replicate in postgres.

      --

      @JAPH = qw(Hacker Perl Another Just);
      print reverse @JAPH;
      • And of course - just to make life interesting - I can't just use an int in postgres I have to use int2, int4, int8 etc.. how annoying - why not go the whole hog and have char8, char9, char10 gaah! I find this especially hateful when I have to write a function to build a cast from just to be able to treat boolean results as either 0 or 1.
        --

        @JAPH = qw(Hacker Perl Another Just);
        print reverse @JAPH;
        • Yes, you can just use an integer. It really does just work as expected:

          % psql test
          test=# create table foo (bar integer);
          test=# \d foo
                Table "public.foo"
          Column |  Type   | Modifiers
          -------+---------+-----------
          bar    | integer |

          And why are you casting from boolean to integer anyway. Is this down to the fact that you've assumed integers instead of booleans everywhere in your code because you're used to MySQL (which AFAIK didn't have proper boolean columns fo

          • I am using aggregation (MIN,COUNT) on the results of an IF, which always returns boolean. Postgres doesn't let you do that without writing a function and using it in a user-defined cast - MySQL DWIM, in fact that's the thing about MySQL - it may not always do STRICTLY the right thing, but 99.99% of the time it DWIM, and that is a whole lot more useful.
            --

            @JAPH = qw(Hacker Perl Another Just);
            print reverse @JAPH;