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 <t...@sss.pgh.pa.us> wrote:
From: Tom Lane <t...@sss.pgh.pa.us>
Subject: Re: [GENERAL] Problem with Check Constraint in pg_restore
To: "Alan Millington" <admilling...@yahoo.co.uk>
Cc: pgsql-general@postgresql.org
Date: Monday, 13 July, 2009, 3:06 PM
Alan Millington <admilling...@yahoo.co.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
