Re: Check constraint failure messages - Mailing list pgsql-general

From Miles Elam
Subject Re: Check constraint failure messages
Date
Msg-id CAALojA-=iKKp-YuHwY=RKT9ow=AdKKG1iYK674AVw5PdTcXTzg@mail.gmail.com
Whole thread Raw
In response to Re: Check constraint failure messages  (Miles Elam <miles.elam@productops.com>)
List pgsql-general
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.elam@productops.com> wrote:
On Tue, Apr 6, 2021 at 1:59 PM Ron <ronljohnsonjr@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.

pgsql-general by date:

Previous
From: Kevin Brannen
Date:
Subject: RE: Check constraint failure messages
Next
From: Siddhartha2485
Date:
Subject: Re: ERROR : invalid transaction termination : PostgreSQL v12