support `defer` statement

[BugenZhao]

We may support the defer statement to do some clean-ups. There're several cases:

• We've created too many materialized views, and the dependency becomes too complex to resolve and write the drop statements correctly. With defer, that'll be natural.
• We may create tables with the same name in multiple tests. If one fails, others may also fail because of not dropping the table: we may also allow defer to clean-up on failures.
• We may not want to make control mode or session variable configurations bring side effects for other parts in this session.

[xxchan]

Cool! I think this is a nice-to-have feature.

But the problem 1/2 (clean-up) can be alternatively solved (or bypassed) by -j1 😄.

For the .part problem, this solution can partly solve it, but I think it's still not the best way. IMO include subtest1.part should be (able to be) parallized (but maybe another syntax e.g., subtest subtest1.part). If so, the session-level side effects can also be isolated.

[BugenZhao]

But the problem 1/2 (clean-up) can be alternatively solved (or bypassed) by -j1 😄.

You're really clever! 😄

[BugenZhao]

But the problem 1/2 (clean-up) can be alternatively solved (or bypassed) by -j1 😄.

But we may also want to test the drop statement. 🥵

[xxchan]

But the problem 1/2 (clean-up) can be alternatively solved (or bypassed) by -j1 😄.

But we may also want to test the drop statement. 🥵

drop is tested in a single slt? Or what case do you mean.

[BugenZhao]

But the problem 1/2 (clean-up) can be alternatively solved (or bypassed) by -j1 😄.

But we may also want to test the drop statement. 🥵

drop is tested in a single slt? Or what case do you mean.

We want to test the correctness of the drop statements, but we may not want to resolve the dependencies manually to write the lines in order. 🤣

[xxchan]

Yes, so I said your proposal is a nice-to-have feature 🤤