Karl Lehenbauer <karl at flightaware.com> writes:
> We ran across a problem where we wanted to delete a column in a table
> and didn't recognize that that column was used as a unique key index
> (nonprimary) by slony.
>
> We did the "best practice" of testing it inside a BEGIN-ROLLBACK to
> make sure that it would go and then pushed it through
> slonik_execute_script and the effect was that all the slony triggers
> got dropped on the master.
>
> We won't make that mistake again.
>
> I guess this is impossible to easily detect and refuse to perform as
> you can't put triggers on "alter table" but could it maybe be made to
> still restore the triggers?
>
> Just a thought...

That suggests a DDL regression test :-).

I would *think* that if you drop that column, thereby making the
"candidate PK" go away, this should lead to an exception, thereby
causing the EXECUTE SCRIPT to roll back *without harm.*

I love the idea of adding a DDL script test where, as part of the DDL
script, we drop out the candidate PK, and validate that this EXECUTE
SCRIPT request fails.

In looking at alterTableForReplication(), it *looks* like it ought to
notice, and reject, this problem, but I'm certainly inclined to add a
test to make sure it does so.

Does that strategy sound useful?
-- 
"cbbrowne","@","acm.org"
http://www3.sympatico.ca/cbbrowne/linuxdistributions.html
In the name of the Lord-High mutant, we sacrifice this suburban girl
-- `Future Schlock'