Shuffle logic in find() a bit, no functional changes
The merger failing is no longer a possibility after 8e40a627

Remove the useless try{} block
Deprecate _build_unique_cond, move its guts to ::ResultSource where it belongs
Properly throw on FC with find (it can never work anyway)

This is the proper solution for RT#95054
A little cleanup of ->id callsites (incomplete)

This is just to stave off an unlikely but possible 'id' colname masking a
multicol PK

The real workaround is to do something akin to Moose's ->meta, but that's
another battle.
More diag from t/53lean_startup.t when under smoker env

Trying to pinpoint cause for the following two:
http://www.cpantesters.org/cpan/report/c13d6ffc-6bf4-1014-8850-81d5948d76d3
http://www.cpantesters.org/cpan/report/51d7cbe3-6bf5-1014-88de-68e8687ecb02
Revert improved test added in b6b8f72f, replace with original from dabe173a

The new test contains a case which it *seems* to me needs to be an exception.
Since we are already pretty late with 28, I am just reverting the test alone
(while keeping the changes). This way I am not backing myself into a corner
with a published test in 29.
Check relationship declarations more consistently
The fix in f9b5239ac was both shortsighted and insufficient

Move the quote_names => quote_identifiers inferrence into ::Storage::DBI
proper, and ensure tests cover it this time

Also bump SQLT dep, as the previous version throws on diffing DBICTest::Schema
under SQLite
Kill rel-exists sanity checks for 28, reinstate them later

Something that simple allows RapidApp to pass its tests without modifications
in other words - worth the pain
Remove unused leftover from c19ca6e80 - there was much flailing :(
The extra reltype flag is breaking some suites - make the full change

Might as well get this over with, still consistent with Swindon
Ensure proper behavior when quoting is *disabled* (wraps up 08ac7648)
"Fix" symptoms described in ba7892a8c4 (I still do not entirely get it)

Extra fail reports are:
http://www.cpantesters.org/cpan/report/f74def2b-6bfb-1014-b341-c67b58fe2ee5
http://www.cpantesters.org/cpan/report/3123ab19-6bf8-1014-b488-656aa945bbef
strip schema name from ADD CONSTRAINT / CREATE INDEX

 * Pg tablenames may have a schema prefix.  This leads to invalid ADD
   CONSTRAINT / CREATE INDEX statments being generated by ->deploy(),
   since constraint and index names may not have a period in them. This
   patch strips the schema part from the table name when constructing
   unique index and constraint names.  The fix was taken from
   ribasushi's email to the mailing list:

   http://lists.scsys.co.uk/pipermail/dbix-class/2013-February/011141.html
Cosmetic rearranging/renaming of some parts of the populate codepath

Zero functional changes
Fix both a dubious test and a regression in populate args immutability

The rewrite in d0cefd99 optimized populate enough that the same data structure
would now make it all the way to the stringifier in ::Storage. This was not
caught due to a deficient test.

Read diff under -w for maximum sense
Deprecate insert_bulk - we will be changing its signature down the road

Besides there is really no reason for users to call it directly
Fix $rs->populate with column name array but no row data

Two regressions for both context types snuck in during the the big populate()
rewrite d0cefd99

- In scalar context the return value incorrectly went from () to []
- In void context an empty $data was handed to ::Storage::_insert_bulk
Simplify some ::Storage::DBI methods (no tempvars)

No functional changes at all