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

      Postgres does have some strengths - user defined functions, user defined casts, and, importantly, robust and effecient transactions, constraints, subselects and stored procedures.

      Of course the projects I'm currently using postgres for - utilise none of those features and would be much quicker and easier in MySQL.

      --

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