Re: Problems with Error Messages wrt Domains, Checks

On Mon, Mar 19, 2018 at 8:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > Frankly, I'm not seeing "invalid constant regular expressions" as being a
> > large scale problem - but I'll agree that having the error include the
> > actual literal being parsed as a RegEx should be done.
>
> Agreed. Doing anything about the other stuff discussed in this thread is
> fairly large-scale work, but adjusting our regex error messages is easy.
> ​[...]
>
> But I wonder if we wouldn't be better off to put the regex into a
> detail line, ie
>
> errmsg("invalid regular expression: %s", ...),
> errdetail("Regular expression is \"%s\".", ...),
>
> The reason I'm concerned about that is I've seen some pretty hairy
> regexes, way longer than are reasonable to include in a primary
> error message. The one-line way is nice for short regexes, but
> it could get out of hand.

​I write many of those - albeit less so when working with database embedded
expressions as opposed to application-layer.

I'd consider at least supplying the first 30 or so characters (or maybe up
to the first newline, whichever is shorter) in the main message and then
the entire regex in the detail line.

invalid regular expression starting with: %s

I think having the typical regex in the message will aid users that use
client interfaces that don't propagate error detail by default - and it
should be sufficient to narrow down, if not pinpoint, the offending regex
in most cases. And, faced with multiple, the user can add a leading
comment to the regexp to help narrow down the options if necessary.

David J.