On Mon, Mar 19, 2018 at 8:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.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.