Following up in case someone else runs into this problem. I changed the function the CHECK statement called to raise a warning. Not perfect, but noticeably better. I don't get the column that failed but I do get what bad input gummed things up.
CREATE OR REPLACE FUNCTION po.confirm(p_val anyelement, p_validated boolean) RETURNS boolean LANGUAGE plpgsql STRICT IMMUTABLE PARALLEL SAFE AS $$ BEGIN IF NOT p_validated THEN RAISE WARNING 'Invalid value: %', p_val; END IF; RETURN p_validated; END; $$; COMMENT ON FUNCTION po.confirm(anyelement,boolean) IS 'Raises a warning when a condition is false; useful for outputting CHECK constraint error values.'; CREATE DOMAIN po.email AS varchar CHECK (po.confirm(VALUE, VALUE IS NULL OR NOT po.email_expanded(VALUE) IS NULL)); Code is not seamless or DRY, but manageable. - Miles On Tue, Apr 6, 2021 at 2:18 PM Miles Elam <miles.e...@productops.com> wrote: > On Tue, Apr 6, 2021 at 1:59 PM Ron <ronljohnso...@gmail.com> wrote: > >> >> The blunt force answer is to not use bulk inserts. Try COPY; it's good >> at saying which record throws an error. >> > > Sadly, this is a cloud-managed database without direct access to 5432 from > outside the VPC and bastian instances are frowned upon by our security > folks. Guess I'm stuck with bisecting. Thanks for the confirmation. > >