Re: Preserving data after updates

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

In response to

Responses

Browse pgsql-general by date

  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.

Browse pgsql-hackers by date

  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