Yes -- It checks that the given vendor has the given vendor_type by calling fn_get_vendor_types_by_vendor(), which gets its data from another table, tb_vendor_vendor_type (a join table between tb_vendor and tb_vendor_type):
CREATE OR REPLACE FUNCTION public.fn_vendor_has_vendor_type(in_vendor integer, in_vendor_type integer)
RETURNS boolean
LANGUAGE plpgsql
STABLE STRICT
AS $function$
BEGIN
IF in_vendor_type IN( SELECT fn_get_vendor_types_by_vendor( in_vendor ) )THEN
RETURN TRUE;
ELSE
RETURN FALSE;
END IF;
END
$function$
I've installed this function on tb_project_vendor, which has a vendor_type column:
So when the data for tb_project_vendor is restored before the data for tb_vendor_vendor_type, I get errors on restore.
I know that this is stretching the limit of what a check constraint is
meant to be, but is there a way, short of editing the pg_restore list manually every time, to guarantee that the table used for validation is populated before the table with the data being validated?
What for? If the dumps actually are taken without contraints, data restored (much faster as no constraints have to be checked, and just then constraints are added via ALTER TABLE.
So you suggest I use a trigger instead of a constraint?
Thanks
--
Moshe Jacobson Nead Werx, Inc. | Manager of Systems Engineering
