Hey Fabian, Thanks for bringing this up and looking into it. It's not great that the behavior changed, but reverting in a next minor is a valid path. +1 to it, and to standardizing this across functions.
Kind regards, Gustavo On Tue, 14 Jul 2026 at 04:09, dylanhz <[email protected]> wrote: > Sure, I’ve opened FLINK-40141 for these functions: > > https://issues.apache.org/jira/browse/FLINK-40141 > > ---------- > Best regards, > dylanhz > > > > > > 2026年7月13日 22:33，Fabian Hueske <[email protected]> 写道： > > > > Hi everyone, > > > > Thanks for the feedback so far. > > I'll start working on this and will open a PR soon. > > > > @dylanhz, thanks for checking the other functions! > > Would you mind opening a ticket for these? > > > > Best, Fabian > > > > Am Sa., 11. Juli 2026 um 10:33 Uhr schrieb dylanhz <[email protected]>: > > > >> Hi Fabian, > >> > >> +1 to align with the SQL standard and other vendors. > >> > >> I also noticed that IS_DECIMAL, IS_DIGIT, and IS_ALPHA return FALSE for > >> NULL input. They may be worth reviewing separately for consistency. > >> > >> > >> ---------- > >> Best regards, > >> dylanhz > >> > >> > >> > >> > >>> 2026年7月9日 21:24，Fabian Hueske <[email protected]> 写道： > >>> > >>> Hi folks, > >>> > >>> I'd like to discuss FLINK-39943 [1]. > >>> Today, Flink's IS JSON / IS NOT JSON functions are hard-coded to never > >>> return NULL. > >>> The recent Calcite 1.38.0 upgrade (FLINK-36602) changed Calcite's own > >>> default to the standard-compliant behavior instead: IS JSON is a > >> predicate > >>> subject to three-valued logic and should evaluate to UNKNOWN (NULL) > when > >>> the input is NULL, not FALSE. > >>> Flink currently suppresses this new Calcite default to preserve the > old, > >>> standards-incompatible semantics [2]. > >>> I've checked a few other engines and all agree with the standard here. > >>> Oracle, PostgreSQL (16+), SQL Server (ISJSON), MySQL (JSON_VALID), and > >>> Snowflake (IS_OBJECT/IS_ARRAY/CHECK_JSON) all return NULL/UNKNOWN for a > >>> NULL input. > >>> > >>> Originally, Flink implemented the correct nullable behavior when the > >>> functions were added in Flink 1.11. For Flink 1.15, this was hotfixed > [3] > >>> to comply with Calcite's non-null semantics. > >>> Since Calcite fixed its definition with the 1.38 release, I'm proposing > >>> that we revert the Flink 1.15 hotfix, even though it's a breaking > change. > >>> > >>> * PRO: standards compliance, consistency with every other engine and > with > >>> Calcite's own default (less surprise porting SQL from other systems), > >>> consistency with Flink's other JSON functions which already propagate > >> NULL, > >>> and removing custom codegen that fights Calcite on every future > upgrade. > >>> * CON: it's a breaking change, most notably flipping NULL IS NOT JSON > >> from > >>> TRUE to NULL, which can affect existing filters, views, or NOT > NULL-typed > >>> computed columns/sinks built on this predicate, and there's no > >>> compatibility flag today to ease the transition. > >>> > >>> This is one of several breaking side-effects of the Calcite 1.38.0 > >>> upgrade. Hence, I'd propose treating it as a deliberate, documented > break > >>> targeted at the next minor version (2.4) rather than adding a dedicated > >>> config flag. > >>> > >>> Curious to hear if others agree, or see a strong case for keeping the > >>> current NOT NULL semantics. > >>> > >>> Best, > >>> Fabian > >>> > >>> [1] https://issues.apache.org/jira/browse/FLINK-39943 > >>> [2] > >>> > >> > https://github.com/apache/flink/commit/8de3293e2d#diff-53c19443d4ddaabe90d0041379f3656f3d52983ae7a0226a9b23bc87675471a8R93 > >>> [3] > >>> > >> > https://github.com/apache/flink/commit/74146c626edd7603f00a6f0c90c7fccaf2066912 > >> > >> > >
