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.
>
>

Reply via email to