Improvements to feature flagging and handling of breaking changes about questdb HOT 3 OPEN

providing a config option is relatively low impact long term

I know @bluestreak01 has a different view, but I disagree with this sentiment. Config options are evil! :)

Each config option:

1. Makes the product more complicated. Important options (say timeouts) or drowning in "compatibility switches" and feature flags.
2. Increases testing surface. You should test different combinations, etc. It gets out of hand quickly.

This is not to say we should never introduce a feature flag or have a policy on it. I merely want to challenge the idea that "switches" and "feature flags" are cheap.

from questdb.

To clarify, what I meant to say was that flags with a narrow scope and (ideally) temporary are cheap, versus wide scope and permanent. I totally agree that we don't want to end up with a ball of feature flag mud!

For that particular feature (choosing whether you want to default to CALENDAR vs FIRST OBSERVATION alignment), it seemed low impact. Even this perhaps should have been a temporary option.

For the other PR, it changes the SQL parser so having a 'get-out' with a temporary flag seemed to be sensible. It means that we can revert the change before release if there's an issue, and we can release bugfixes to users even if they can't migrate yet. It should be removed in the following version except in extenuating circumstances.

Ideally, we wouldn't include any flag for most breaking changes, to keep things simple.

from questdb.

I can agree with that :)

from questdb.