Short-Term Goal

• Add option-style syntax for fillnull:

  fillnull [value=<string>] [<field-list>]
  

• value is mandatory for now.

• Rationale: Backward-compatible with current queries and ergonomics, while preserving strict, schema-stable behavior.

Long-Term Goal (aligned with permissive mode)

Introduce an opt-in permissive/schemaless execution mode so fillnull (and related expressions) can gracefully handle mixed types

See detailed planning at:
#4349

Current State

• Syntax today:

  • fillnull with <replacement> [in <field-list>]
  • fillnull using <field>=<replacement> [, <field>=<replacement> ...]

• Typing today: Lowered to standard COALESCE(field, <value>) (type-strict, returns original field type); single replacement across mixed types errors.

Proposal

• Short term: Add the option-style surface (fillnull [value=<string>] [<field-list>]) alongside existing forms; semantics remain strict and schema-preserving; require value=.
• Long term: Implement the permissive/schemaless mode described above

Examples (short term behavior)

• Same-typed fields:

  source=logs | fillnull value=0 response_time, status_code
  

  (Equivalent to fillnull with 0 in response_time, status_code)

• Apply to all fields (strict typing still applies, all fields must be strings in this case):

  source=logs | fillnull value="missing"
  

• Mixed-type workarounds today:

  source=logs | fillnull using host="N/A", response_time=0
  -- or
  source=logs | fillnull with "N/A" in host | fillnull with 0 in response_time
  

• Type coercion failure (today, single replacement across mixed types):

  source=logs | fillnull value="N/A" host, response_time
  

  Representative error:

  {
    "error": {
      "reason": "Invalid Query",
      "details": "Cannot infer return type for COALESCE; operand types: [INTEGER, VARCHAR]",
      "type": "IllegalArgumentException"
    },
    "status": 400
  }