On Mon, Mar 19, 2018 at 9:11 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> "David G. Johnston" <david.g.johns...@gmail.com> writes:
> > On Mon, Mar 19, 2018 at 8:33 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> >> 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\".", ...),
>
> > 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.
>
> That seems like a lot more complication than this is worth, and it'd be
> confusing to users as well, if things are formatted differently for short
> and long regexes.
> ​
>
They would be formatted the same every time - just need to remember to add
the extra function call around the expression variable in the errmsg case.
Definitely not married to the idea though.
Saying "begins with" and then showing the entire regex shouldn't cause too
much confusion I'd hope.
> I thought
> about trying to discourage deviations by using common error-reporting
> subroutines, but there are enough legit differences in what needs to
> be done that that might not work well.
>
​Two support functions might suffice:​
present_regexp_for_errmsg(regex_var)
present_regexp_for_detailmsg(regex_var)
We can at least centralize how the expression itself is string-ified.
David J.
​
