Skip to content

IGNITE-28896 SQL Calcite: Support BigDecimal for FETCH, OFFSET and LIMIT - #13375

Open
tkalkirill wants to merge 9 commits into
masterfrom
ignite-28896
Open

IGNITE-28896 SQL Calcite: Support BigDecimal for FETCH, OFFSET and LIMIT#13375
tkalkirill wants to merge 9 commits into
masterfrom
ignite-28896

Conversation

@tkalkirill

Copy link
Copy Markdown
Contributor

@tkalkirill tkalkirill changed the title IGNITE-28896 Wip IGNITE-28896 SQL Calcite: Support BigDecimal for FETCH, OFFSET and LIMIT Jul 15, 2026
@zstan

zstan commented Jul 19, 2026

Copy link
Copy Markdown
Contributor

So, it need to be merged somehow ? #13311
I don`t understand about rounding policy, this policy need to be applied globally for all rounding operations not only for limit\offset

@tkalkirill

tkalkirill commented Jul 20, 2026

Copy link
Copy Markdown
Contributor Author

@zstan BigDecimal is already in Calcite's main branch, so I think it makes sense to use that.
Regarding the rounding policy: the name FetchOffsetRoundingPolicy implies it doesn't cover all rounding, but specifically OFFSET and FETCH, and the documentation describes it that way as well.

rowType,
idxBndRel.first() ? cmp : cmp.reversed(),
0,
SortNode.OFFSET_DEFAULT,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I specially not touch this in my PR ) What more informative ?
node with OFFSET_DEFAULT param - it need to lookup for reviewer or node with concreete "0" param ?
Of course it`s all kinda taste ... I just show you my logic here

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point. My intention is to express the semantics of this positional argument: no offset is specified here. The reader does not need to look up the constant value unless implementation details matter, while 0 shows the value but not the intent. It also keeps this call consistent with the defaults defined by SortNode, so I’d prefer to keep it.

else {
SqlTypeName paramType = typeFactory().createType(param.getClass()).getSqlTypeName();
err = IgniteResource.INSTANCE.incorrectDynamicParameterType(SqlTypeName.BIGINT.toString(), paramType.getName());
err = IgniteResource.INSTANCE.incorrectDynamicParameterType(SqlTypeName.DECIMAL.toString(), paramType.getName());

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

say once more: this is wrong fix !

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? That’s how it is in the CALCITE main branch right now.

public void testFetchOffsetRoundingPolicy() throws Exception {
fillCache(cacheRepl, 4);

FetchOffsetRoundingPolicy floorPlc = value -> value.setScale(0, RoundingMode.FLOOR);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we do not need to test Calcite configuration setting, we need to fix it in our code and use over all functionality and tests, otherwize we need to give an ability to configure it through Ignite setting which is discussable.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t think this needs to become a public Ignite setting. Rounding semantics may depend on the required SQL compatibility mode, so having one hardcoded behavior for every use case is unnecessarily restrictive.
This policy is an internal Calcite extension point intended for advanced integrations, not a part of the public Ignite API. The default behavior is still used everywhere unless a custom policy is explicitly provided. Keeping it internal also allows us to evolve or replace the mechanism later without introducing a public API compatibility burden.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants