Use pg-specific schema tables for fkey detection

- Postgres doesn't care about names for uniqueness of keys unlike mysql
  because internally it keeps "oid" values to keep track of everything.
  Unfortunately this means that the information_schema standard is
  inadequate to differentiate between constraints that are named the
  same (which isn't possible in mysql, but is in pg). Hence we have to
  dip into the pg specific schemas for better or worse.
- Fix naming of the sample schema in the README since it would fail for
  mysql due to duplicate naming.
- Mark test schema up so we don't fix the bad names so we catch
  regressions here.
- Fix #85

testdata/postgres_test_schema.sql

@@ -400,6 +400,7 @@ CREATE TABLE jets (
 );
 
 ALTER TABLE jets ADD CONSTRAINT jet_pkey PRIMARY KEY (id);
+-- The following fkey remains poorly named to avoid regressions related to psql naming
 ALTER TABLE jets ADD CONSTRAINT pilots_fkey FOREIGN KEY (pilot_id) REFERENCES pilots(id);
 
 CREATE TABLE languages (
@@ -417,5 +418,6 @@ CREATE TABLE pilot_languages (
 
 -- Composite primary key
 ALTER TABLE pilot_languages ADD CONSTRAINT pilot_language_pkey PRIMARY KEY (pilot_id, language_id);
+-- The following fkey remains poorly named to avoid regressions related to psql naming
 ALTER TABLE pilot_languages ADD CONSTRAINT pilots_fkey FOREIGN KEY (pilot_id) REFERENCES pilots(id);
 ALTER TABLE pilot_languages ADD CONSTRAINT languages_fkey FOREIGN KEY (language_id) REFERENCES languages(id);