Re: Domain Constraint Violation Error Messages
От | Andres Freund |
---|---|
Тема | Re: Domain Constraint Violation Error Messages |
Дата | |
Msg-id | 20180725163521.e3bkogqqktvb7i76@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Domain Constraint Violation Error Messages ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | 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 по дате отправления: