> By the way, I think the "MyRewards" alterations probably break...  If
> memory isn't disserving me, you can't SET NOT NULL until you have
> updated all existing tuples to have values...

I think it will work if you use one alter command with all the
alterations you meant for MyRewards. In that case postgres will rebuild
your table and set the new column to the default value you provided -
but beware that it will take some time if the table is big...

Here I do it in a few distinct steps:

1) add the column without default (that would rebuild the table) and
without not null (that fails);

2) add the default clause so new columns are initialized properly;

3) set the new column to the default value for the existing rows (in
chunks to avoid contention, and sorted to avoid deadlocks, our code is
mostly bulk updating sorted the same in all places to avoid deadlocks);

4) add the not null;

Sometimes I don't even need the default clause to stay there, but I use
it to have new rows take that value directly so I don't need to update
them again... and that helps adding the not null later. In those cases
after migration to the new application version which properly sets the
new field I drop the default clause.

One more thing: adding the field and setting it to the default value is
overall a lot more faster than the chunked update method. If you can
afford a downtime for that go for it. And if you choose chunking, don't
forget to vacuum in the meantime... or you're table will bloat
considerably.

HTH,
Csaba.