Tom Lane wrote:
conname | consrc ---------------------------+---------------------------------------------------------------------------------------------------------What do you get from
select conname, consrc from pg_catalog.pg_constraint where contype = 'c' and conrelid = 'person'::regclass;
person_e_mail_address | public.check_pattern((e_mail_address)::character varying, 'Internet E-Mail Address'::character varying)
person_name_check | ((last_name IS NOT NULL) OR (first_name IS NOT NULL))
person_social_security_no | public.check_pattern(social_security_no, 'Social Security Number'::character varying)
(3 rows)
select conname, consrc from pg_catalog.pg_constraint
where contype = 'c' and conrelid = 'person_change_history'::regclass;
conname | consrc ---------------------------+--------------------------------------------------------------------------------------------------
person_social_security_no | check_pattern(social_security_no, 'Social Security Number'::character varying)
person_name_check | ((last_name IS NOT NULL) OR (first_name IS NOT NULL))
person_e_mail_address | check_pattern((e_mail_address)::character varying, 'Internet E-Mail Address'::character varying)
(3 rows)
AFAICS from looking at the 7.3 pg_dump source, it should suppress anyInteresting. The consrc column values differ in that the explicit schema qualification on the function calls is missing for the descendent table. So, you think maybe if I remove the explicit schema qualification from the function calls in the constraint declarations on the person table that that might fix it? Yup! That does it!
constraint on person_change_history that looks identical to one of the
parent table's constraints in this query.
Thanks for your help.
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
