Re: Problem with Check Constraint in pg_restore

Thank you for that.
 
Having done some further investigation I had concluded that the problem was probably with the LIKE (~~) comparison. I created a text dump file with the -d (use INSERT rather than COPY) option so that I could see which rows failed. All of the rows which exercised the LIKE test failed, and all those that did not succeeded.
 
I remain a bit puzzled as to why the comparison should work one way when INSERT or COPY is invoked from pgAdmin III, and another when COPY is invoked from pg_restore or INSERT is contained in a file fed to psql. Be that as it may; I shall take your advice, and use EXTRACT instead, if that is going to be more robust.

--- On Mon, 13/7/09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [GENERAL] Problem with Check Constraint in pg_restore
To: "Alan Millington" <admillington(at)yahoo(dot)co(dot)uk>
Cc: pgsql-general(at)postgresql(dot)org
Date: Monday, 13 July, 2009, 3:06 PM

Alan Millington <admillington(at)yahoo(dot)co(dot)uk> writes:
> CONSTRAINT "RP_DATE_check" CHECK (date IS NULL AND accuracy = '?'::bpchar OR date IS NOT NULL AND date > '1099-12-31'::date AND (accuracy = 'D'::bpchar OR accuracy = 'M'::bpchar AND date::text ~~ '%-01'::text OR (accuracy = 'Y'::bpchar OR accuracy = '?'::bpchar) AND date::text ~~ '%-01-01'::text))

These ~~ (LIKE) tests on date columns seem horribly unsafe.  I suspect
your problem is that you're trying to load the data with DateStyle
set to some setting other than what this constraint is hard-wired
to assume.  Personally I'd suggest replacing the LIKEs with something
using EXTRACTs, or some other way that doesn't depend on the textual
formatting of dates.

            regards, tom lane