On Thu, Oct 2, 2014 at 6:03 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Claudio Freire (klaussfreire@gmail.com) wrote:
>> On Thu, Oct 2, 2014 at 4:40 PM, Stephen Frost <sfrost@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.
