Re: Domain Constraint Violation Error Messages - Mailing list pgsql-bugs

From Andres Freund
Subject Re: Domain Constraint Violation Error Messages
Date
Msg-id 20180725163521.e3bkogqqktvb7i76@alap3.anarazel.de
Whole thread Raw
In response to Re: Domain Constraint Violation Error Messages  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-bugs
On 2018-07-25 09:31:30 -0700, David G. Johnston wrote:
> On Wed, Jul 25, 2018 at 9:19 AM, Benjamin Coutu <ben.coutu@zeyos.com> wrote:
> 
> > > No way. PG11 has been feature frozen for quite a while.
> >
> > I understand, thanks. I thought, maybe it would qualify as a trivial "bug"
> > fix, sorry for that.
> > Would it be hard to also include column name(s) for PG 12 then?
> >
> 
> IIUC this general problem (it also applies to, e.g., varchar(20)) ​is well
> known and has been discussed many times, as recently as the last 6 months
> if memory serves.  The lack of concrete progress, as well as general
> sentiment, leads me to think that the cost-benefit calculation for
> improving things in this area is extremely poor.  It is not an easy (and,
> likely inexpensive run-time effort) thing to add context to what is a
> simple type input function error.

I think the INSERT ... VALUES() case is actually comparatively
simple. Both code and runtime complexity wise.  And that'd probably
solve a large fraction of the need.  Might even be realistic to tackle
the source->table implicit casts, without adding too much overhead.

If you're instead talking about doing something for every possible use
of a domain, then the problem obviously gets way more complicated.

Greetings,

Andres Freund


pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Domain Constraint Violation Error Messages
Next
From: Tom Lane
Date:
Subject: Re: Domain Constraint Violation Error Messages