Tighten up schema of the migrations table a little more

[brandur]

I'd totally forgotten I'd even created it this way, but going back through migrations recently I realized that the table's primary key is a bigserial.

This isn't totally bad, and even has some advantages in that rows are easier to target from a psql session, but in this instance it feels a little on the sloppy side because it's fairly easy to conflate the serial with migration version -- both are expected to be small integers that a human could easily mix up.

Since we haven't shipped a new version yet containing the addition of line in #435, here I propose that we modify that a little further to reshape river_migration into a slightly smaller table with a compound key on (line, version):

CREATE TABLE river_migration(
    created_at timestamptz NOT NULL DEFAULT NOW(),
    line TEXT NOT NULL,
    version bigint NOT NULL,
    CONSTRAINT line_length CHECK (char_length(line) > 0 AND char_length(line) < 128),
    CONSTRAINT version_gte_1 CHECK (version >= 1),
    PRIMARY KEY (line, version)
);

This has two tiny side benefits that (1) the table is smaller (drops a column), and (2) we don't need an extra index on (line, version) since it's already covered by the primary key. Very similar in spirit to what it was before, but I think a little cleaner in design.

[brandur]

@bgentry Not high priority, but this design feels a bit cleaner to me. Thoughts?

[brandur]

thx.