From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Benjamin Coutu <ben(dot)coutu(at)zeyos(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Domain Constraint Violation Error Messages |
Date: | 2018-07-25 16:35:21 |
Message-ID: | 20180725163521.e3bkogqqktvb7i76@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)coutu(at)zeyos(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-07-25 16:54:36 | Re: Domain Constraint Violation Error Messages |
Previous Message | David G. Johnston | 2018-07-25 16:31:30 | Re: Domain Constraint Violation Error Messages |