check constraint problem during COPY while pg_upgrade-ing

[Karsten Hilbert <Karsten.Hilbert@xxxxxxx>]

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


-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general