Simon,
* Simon Riggs (simon@2ndQuadrant.com) wrote:
> Agreed, but that is also be a silent change of current behaviour.
Sure, proper MVCC for catalog entries would be a change, but I think
it's one which would actually reduce the surprises for our users. Today
we tell people we have transactional DDL, and that's somewhat true, but
it's not MVCC-safe and that can lead to surprises.
> But the above will only work for CREATE TABLE, not for TRUNCATE.
I'm trying to figure out why there are all the constraints around this
command to begin with. If we're going to support this, why do we
require the user to create or truncate the table in the same
transaction? Clearly that's going to reduce the usefulness of this
feature and it's not clear to me why that constraint is needed,
code-wise.
Also, what about adding FREEZE options to INSERT and maybe even UPDATE?
Surely it would reduce the overhead associated with those commands as
well.
> I've invested a lot of time in trying to improve the situation and
> investigated many routes forwards, none of them very satisfying. Until
> someone comes up with a better plan, FREEZE is a pragmatic way
> forwards that improves things now rather than waiting for the perfect
> solution.
I agree that the perfect can sometimes be the enemy of the good, but I
still feel that this is quite a slippery slope that's going to end up
getting ourselves into trouble- regardless of how much we document it or
set up constraints around it.
> And if we want checksums anytime soon we need ways to
> ameliorate the effect of hints on checksums, which this does,
> soemwhat.
I don't buy into this argument in the least.
> Better plans, with code, welcome.
While I appreciate the mentality that those-who-code-win, I don't
believe that it can be used in an argument based on *correctness*.
Thanks,
Stephen