sql: allow 'set default' cascading action when default is implicit null

[rolandcrosby]

While digging into #38933, @tyler314 ended up hitting an error involving this test:

statement ok
CREATE TABLE a (
  id STRING PRIMARY KEY
);
CREATE TABLE b (
  id STRING PRIMARY KEY
 ,a_id STRING DEFAULT NULL UNIQUE REFERENCES a ON DELETE SET DEFAULT
);
CREATE TABLE c (
  id STRING PRIMARY KEY
 ,b_a_id STRING REFERENCES b(a_id) ON UPDATE CASCADE
);

It turns out that removing the explicit DEFAULT NULL on b.a_id hits this error; we forbid set default cascading actions on any column without a default expression. However, elsewhere we treat null as the default default, so to speak; every column lacking an explicit 'default' expression should be treated as default null. And Postgres doesn't even distinguish between explicit default null and a lack of a default expression. As such, Postgres will happily execute the above CREATE TABLE statements even without the explicit DEFAULT NULL in b.a_id:

postgres=# select version();
                                                     version
-----------------------------------------------------------------------------------------------------------------
 PostgreSQL 11.4 on x86_64-apple-darwin18.6.0, compiled by Apple LLVM version 10.0.1 (clang-1001.0.46.4), 64-bit
(1 row)

postgres=# create table a (
  id varchar primary key
);
CREATE TABLE
postgres=# create table b (
  id varchar primary key
, a_id varchar unique references a on delete set default
);
CREATE TABLE
postgres=# create table c (
  id varchar primary key
, b_a_id varchar references b(a_id) on update cascade
);
CREATE TABLE

[tyler314]

What was the most confusing to me, is how do we hit this error in the case where the user explicitly sets DEFAULT NULL, but not when they do so implicitly. After my change, the Default Expression in the column is nil in both cases, but we only hit the error in the explicit case. Will continue to dig a little deeper.