Currently, we use the same tree.DNull singleton to represent the NULL datum for all types. However, this causes inconsistencies with Postgres.
In Postgres, the NULL datum seems to carry some type other than unknown with it:
marcus=# CREATE TYPE typ AS ENUM ('foo', 'bar', 'baz');
CREATE TYPE
marcus=# SELECT enum_range(NULL::typ);
enum_range
---------------
{foo,bar,baz}
(1 row)
In CRDB, evaluating the same expression is impossible because NULL's type is always unknown:
defaultdb> CREATE TYPE typ AS ENUM ('foo', 'bar', 'baz');
CREATE TYPE
defaultdb> SELECT enum_range(NULL::typ);
ERROR: enum_range(): argument cannot be NULL
SQLSTATE: 22004
NOTE: I'm not exactly sure that Postgres NULL datums carry some type with them during evaluation. There could be some other mechanism at play that allow evaluation of the example above.
Currently, we use the same
tree.DNull
singleton to represent theNULL
datum for all types. However, this causes inconsistencies with Postgres.In Postgres, the
NULL
datum seems to carry some type other thanunknown
with it:In CRDB, evaluating the same expression is impossible because
NULL
's type is alwaysunknown
:NOTE: I'm not exactly sure that Postgres NULL datums carry some type with them during evaluation. There could be some other mechanism at play that allow evaluation of the example above.
Epic CRDB-2474 Jira issue: CRDB-14090