From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Berend Tober <btober(at)seaworthysys(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Preserving data after updates |
Date: | 2005-05-19 21:27:18 |
Message-ID: | 105.1116538038@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Berend Tober <btober(at)seaworthysys(dot)com> writes:
> I tried a simpler example than my original, as you have, and the problem
> bahavior didn't manifest, but it still happens in my dev copy of my
> production database. The immediately obvious difference between the
> simpler example, like yours, and the actual case in which the problem
> manifests is that the problem case to of the table constraints call a
> user-defined function "check_pattern()" (which tests the column value
> against a regular expression), i.e.
Nope, that's not it. Still works fine here.
What do you get from
select conname, consrc from pg_catalog.pg_constraint
where contype = 'c' and conrelid = 'person'::regclass;
select conname, consrc from pg_catalog.pg_constraint
where contype = 'c' and conrelid = 'person_change_history'::regclass;
AFAICS from looking at the 7.3 pg_dump source, it should suppress any
constraint on person_change_history that looks identical to one of the
parent table's constraints in this query.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2005-05-19 21:47:59 | Re: numeric precision when raising one numeric to another. |
Previous Message | Dann Corbit | 2005-05-19 21:25:58 | Re: numeric precision when raising one numeric to another. |
From | Date | Subject | |
---|---|---|---|
Next Message | Berend Tober | 2005-05-20 02:03:57 | Re: Preserving data after updates |
Previous Message | Berend Tober | 2005-05-19 21:14:44 | Re: Preserving data after updates |