On Mon, 11 Feb 2019, Ken Tanzer wrote:
Just in case you miss this little nuance, you don't necessarily _have_ to
specify a NULL for that column, depending how you're doing your inserts.
You haven't show us your table or what INSERT you're using, but all of
these examples will work, and don't specify an explicit NULL:
Ken,
Well, you've succeeded in confusing me. :-)
This is the table's schema:
# \d activities
Table "public.activities"
Column | Type | Collation | Nullable | Default
--------------+-----------------------+-----------+----------+-------------
------------
person_id | integer | | not null |
act_date | date | | not null | CURRENT_DATE
act_type | character varying(12) | | not null | '??'::charac
ter varying
notes | text | | not null | '??'::text
next_contact | date | | |
Indexes:
"activities_pkey" PRIMARY KEY, btree (person_id, act_date, act_type)
Foreign-key constraints:
"activities_act_type_fkey" FOREIGN KEY (act_type) REFERENCES activityty
pes(act_name) ON UPDATE CASCADE ON DELETE RESTRICT
"activities_person_id_fkey" FOREIGN KEY (person_id) REFERENCES people(p
erson_id) ON UPDATE CASCADE ON DELETE RESTRICT
And this is the framwork for adding rows:
insert into Activities (person_id,act_date,act_type,notes,next_contact) values
(
I add values for each column, but if there's no scheduled next_contact date
I left that off. To me, this looks like your second example (with two
columns of values and no date) and I don't see the differences.
Regards,
Rich
