check constraint problem during COPY while pg_upgrade-ing

I have noticed another problem during pg_upgrade on a 9.1
cluster with 9.4 as the target.

Consider this sort of table

    create table therapy (
        pk serial primary key,
        description text,
        is_ongoing boolean not null,
        ts_end timestamp with time zone
    );

Now, business rules say that a particular therapy is either
ongoing or not. The end of therapy can be known or not.
However, if the therapy is ongoing the ts_end must be either
NULL or "in the future" at row INSERT/UPDATE time.

Consider this check constraint

    CHECK (
        (is_ongoing is false)
            OR
        (
            ((is_ongoing is true) AND (ts_end is null))
                OR
            ((is_ongoing is true) AND (ts_end > now()))
        )
    )

(I know this can logically be reduced. I wrote it this way to
be explicit about the intent.)

This works fine, the application (GNUmed) ensures INSERTS and
UPDATES do the right thing with .is_ongoing and .ts_end.

Now the following sequence happens:

- insert row with .is_ongoing=true and .ts_end=tomorrow()
- wait a week
- dump
- restore

The restore will fail because the inserted row contains
.is_ongoing=true and .ts_end<now() ...

Of course, dump/restore can't be expected to know about my
business rules so I wonder what the _suggested_ approach to
this requirement is ?

(Technically one could use a BEFORE INSERT/UPDATE trigger to
 check .ts_end and .is_ongoing.)

Thanks for any input,
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346