Overview

Currently some change types have "don't allow field X" for some databases. For example:

                   cacheSize="20"
                   incrementBy="50"
                   sequenceName="SOME_SEQUENCE"
                   ordered="false"
                   startValue="1"/>

fails on postgresql because "ordered" is not a supported argument.

That causes a problem for a changelog that needs to work with both oracle and postgreql, because for oracle the ordered field CAN be set and we want the same changeset to work for both.

In this case, it's not really that "ordered" is not supported on postgresql, it's that ordered="true" is not supported.

Changes

We need a better way to understand what the default for values are if not set, and only fail validation if non-default values are set.

We probably also need a way for implementations of Changes to say that even the default value is not something that makes sense.

Other possibly connected changes

We have a general pattern of "Sometimes the user specifies something, but we just ignore it for some databases. Sometimes we throw a validation error". For example, for databases that don't support sequences at all, we maybe just ignore createSequence.

Perhaps an overall pattern on what makes sense to ignore and what makes sense to fail and what makes sense to warn needs to be figured out?