At the same time I like MS better in some ways for the same issue because it has auto_increment instead and it is almost all I ever need and it would be a drag to have to use an extra table (not sure it's a full fledged table, but you get the idea) every time.

It's not any kind of a table, it's a sequence, which consumes only a handful of bytes, pretty much exactly like auto_increment does. The big advantage of a sequence over auto_increment is that if you need to you can use more than one sequence in the same table, or share a sequence between tables, which you can't do with MySQL (or couldn't do the last time I looked at it anyway)...

The same goes for the data type ENUM (not sure if PS has SET).

Not sure what you mean by the ENUM, since PostgreSQL does indeed have ENUM, just not in the backwards column-level way MySQL does it, which forces you to redefine the enum in every column you want to use it, even if it should be the same for all those columns.

# MySQL
CREATE TABLE color_choices (
    foreground ENUM ( 'RED', 'GREEN', 'BLUE' ),
    background ENUM ( 'RED', 'GREEN', 'BLUE' )
);

# PostgreSQL
CREATE TYPE colors AS ENUM ( 'RED', 'GREEN', 'BLUE' );
CREATE TABLE color_choices (
    foreground colors,
    background colors
);
[download]

And while PostgreSQL doesn't have SET, it does support array data types, which get you pretty much the same end result, with less work.

# MySQL
CREATE TABLE color_choices (
    favorites SET ( 'RED', 'GREEN', 'BLUE' ),
    least_favorites SET ( 'RED', 'GREEN', 'BLUE' )
);

# PostgreSQL
CREATE TYPE colors AS ENUM ( 'RED', 'GREEN', 'BLUE' );
CREATE TABLE color_choices (
    favorites colors[],
    least_favorites colors[]
);
[download]

Also, if you like SET, you should be sure and read The MySQL SET Data Type, especially the section entitled "Why You Shouldn't Use SET".

Nice rundown, thanks. This was meant for jasonk, of course. So sleepy...