Re: Problems with Error Messages wrt Domains, Checks - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Problems with Error Messages wrt Domains, Checks
Date
Msg-id CAKFQuwbhYv3kX5TrRQANCr7DLmVaNnEdEd=Ef=2nwfnqNRQ-Zw@mail.gmail.com
Whole thread Raw
In response to Re: Problems with Error Messages wrt Domains, Checks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Mar 19, 2018 at 9:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Mon, Mar 19, 2018 at 8:33 AM, Tom Lane <tgl@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.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Problems with Error Messages wrt Domains, Checks
Next
From: Tom Lane
Date:
Subject: Re: Error detail/hint style fixup