On Thu, Oct 2, 2014 at 6:03 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Claudio Freire (klaussfre...@gmail.com) wrote: >> On Thu, Oct 2, 2014 at 4:40 PM, Stephen Frost <sfr...@snowman.net> wrote: >> > The downside of the 'explain' approach is that the script then has to be >> > modified to put 'explain' in front of everything and then you have to go >> > through each statement and consider it. Having a 'dry-run' transaction >> > type which then produces a report at the end feels like it'd be both >> > easier to assess the overall implications, and less error-prone as you >> > don't have to prefex every statement with 'explain'. It might even be >> > possible to have the local "view" of post-alter statements be available >> > inside of this 'dry-run' option- that is, if you add a column in the >> > transaction then the column exists to the following commands, so it >> > doesn't just error out. Having 'explain <whatever>' wouldn't give you >> > that and so you really wouldn't be able to have whole scripts run by >> > just pre-pending each command with 'explain'. >> >> That sounds extremely complex. You'd have to implement the fake >> columns, foreign keys, indexes, etc on most execution nodes, the >> planner, and even system views. > > Eh? We have MVCC catalog access.
And that needs locks, especially if you modify the underlying filesystem layout. >> IMO, dry-run per se, is a BEGIN; stuff; ROLLBACK. But that still needs >> locks. I don't think you can simulate the side effects without locks, > > Why? If you know the transaction is going to roll back and you only add > entries to the catalog which aren't visible to any other transactions > than your own, and you make sure that nothing you do actually writes > data out which is visible to other transactions.. But that's not the scope. If you want a dry-run of table-rewriting DDL, or DDL interspersed with DML like: alter table blargh add foo integer; update blargh set foo = coalesce(bar, baz); You really cannot hope not to have to write data. The above is also the case with defaulted columns btw. >> so getting the local view of changes will be extremely difficult >> unless you limit the scope considerably. > > I agree that there may be complexities, but I'm not sure this is really > the issue.. In essence, if you want MVCC catalog access without AEL, you're in for a rough ride. I'm not as experienced with pg's core as you, so you tell me, but I imagine it will be the case. -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers