third step of 835 for payment_instructions

[chadwhitacre]

Drops the old non-id columns.
#835

• rebase once second step of 835 for payment_instructions #4061 lands

[chadwhitacre]

Blocking on #4061.

[chadwhitacre]

Here's the diff between this PR and #4046, showing scant differences between the result of the one-shot version and the zero-downtime version of the migration, apart from the fixes in #4060 (which are included on the latter but not the former):

https://gist.github.com/whit537/b80dc73755d155d6f1784b65adf955a2

[rohitpaulk]

Rebased on master (@9afc3319d9fa53d0841a6476bfc279037c89bdd4), previous head - @cfbdaf1e586385d1efbf7ad0dc614b1f914cbf68

[rohitpaulk]

Hmm, why do we have to rebuild the view here? (It made sense in the second step (#4061))

[chadwhitacre]

The view includes the participant and team columns (SELECT [...] *), so if we don't drop those columns here then the next steps will fail.

[gratipay] $ psql gratipay-test
Null display is "¤".
Line style is unicode.
Border style is 2.
psql (9.4.5, server 9.3.2)
Type "help" for help.

gratipay-test=# alter table payment_instructions drop column participant;
ERROR:  cannot drop table payment_instructions column participant because other objects depend on it
DETAIL:  view current_payment_instructions depends on table payment_instructions column participant
HINT:  Use DROP ... CASCADE to drop the dependent objects too.
gratipay-test=#

[rohitpaulk]

Aha! Cool.

[rohitpaulk]

Note to deploy: Run sql/branch.sql after code.

[rohitpaulk]

I can't deploy right now - I'll do it in 2 hours if no one else gets to it first

[chadwhitacre]

Okay, I can deploy ...