GitHub PushEvent at 2014-06-18 22:41:49
Repository: sequel
Actor: jeremyevans
Payload: {"shas":[["ccb2b5c6d696786347da00da1f3f62aa36905cbe","e6fb06210fafc02fd7479ddbed2d042cc3a5155e@jeremyevans.net","Use consistent indentation","Jeremy Evans",true],["744fd0f2a8550a3649857fd2c42b67d841e8392c","e6fb06210fafc02fd7479ddbed2d042cc3a5155e@jeremyevans.net","Make Dataset#insert_select on PostgreSQL respect existing RETURNING clause\n\nIn addition to the regular case, this also handles it in the\nprepared statement case.","Jeremy Evans",true],["6c3b240876b1354ccf09f051522bcb73273fdc83","e6fb06210fafc02fd7479ddbed2d042cc3a5155e@jeremyevans.net","Use explicit columns when using automatically prepared SELECT statements in the prepared statement plugins\n\nPreviously, Sequel would use the same SQL in a prepared statement\nas it would in a regular query, except for the placeholders.  In\nmost cases, this resulted in Sequel using SELECT * for SELECT\nqueries.  Unfortunately, databases such as PostgreSQL complain\nfor these types of queries if you are adding columns to a table.\n\nThis can cause problems when running migrations for a concurrently\nrunning application that uses the prepared statements plugin. The\nonly previous alternatives were:\n\n1) Don't use prepared statements while the migration code is running.\n2) Shut down the application while the migration code is running.\n3) Accept that some queries may fail while the migration code is\n   running.\n\nNone of these alternatives were desirable.  With this change, you\ncan safely use the prepared statements plugin while running\nmigrations that add columns to existing tables.\n\nNote that most other forms of schema modification will still cause\nproblems with a concurrently running application (such a renaming\na column), but those issues are not specific to the use of\nprepared statements.","Jeremy Evans",true]],"size":3,"ref":"refs/heads/master","head":"6c3b240876b1354ccf09f051522bcb73273fdc83"}