Logically, that would be reasonable; Tcl doesn't have a native NULL equivalent (it's not a value at all in Tcl's value logic; the closest you get is an absence of a value, which is a variable or dictionary entry that doesn't exist).

The reason I'm asking and proposing this is that I've came up with a similar solution in my Tcl binding for http://www.open62541.org which uses the special break return code in order to signal errors or exceptions in method calls back to the caller but still can deal with normal runtime errors in the method's implementation locally using for example the background error mechanism.

Is it feasible to enhance the Tcl Interface for allowing a Tcl coded SQL function to report an SQL NULL value, e.g. by interpreting the result TCL_BREAK of the Tcl code performing a return -code break ...

With my apologies for the extreme delay on this: that is now checked into a branch and is due to be merged to trunk after the pending 3.50 release.

Your unrelated suggestion in /forumpost/dce85c5ab9f0bc10 is also targeted for 3.51 but is not yet implemented (re-implemented - we have to reimplement it for licensing reasons but will use yours as a blueprint for the feature).

I agree that allowing Tcl-coded SQL functions to return NULL values would be a useful feature, as it would provide more flexibility in handling missing data.

I agree that allowing Tcl-coded SQL functions to return NULL values would be a useful feature

There is no uniform representation of NULL in Tcl. What you can do, as of 3.51, is "return -code break" in place of returning NULL. The end result is still not a NULL, though - it's a string value configured to stand in for Tcl's non-existing NULL.

As relevant snippet from test/tclsqlite.test:

proc breakAsNullUdf args {
  if {"1" eq [lindex $args 0]} {return -code break}
}
do_test tcl-9.4 {
  db function banu breakAsNullUdf
  execsql {SELECT typeof(banu()), typeof(banu(1))}
} {text null}
do_test tcl-9.5 {
  db nullvalue banunull
  db eval {SELECT banu(), banu(1)}
} {{} banunull}

There is no uniform representation of NULL in Tcl.

There is; it's the absent key or unset variable. It's the thing that doesn't exist. TDBC strongly recommends mapping NULL that way.

There is; it's the absent key or unset variable. It's the thing that doesn't exist.

Fair enough. The -withoutnulls option already exists for the array/dict cases, leaving the affected keys unset. UDFs, however, don't set anything - they return a value or (as of recently) may communicate a NULL by "break"ing.

A relevant snippet from one of the test scripts:

# 2017-06-26: The -withoutnulls flag to "db eval".
#
# In the "db eval -withoutnulls SQL TARGET" form, NULL results cause the
# corresponding target entry to be unset.  The default behavior (without
# the -withoutnulls flags) is for the corresponding target value to get
# the [db nullvalue] string.