"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.
At least, it is if we can get consensus on what they should look like :-).
There's at least one place that already includes the regex proper in
its error, in hba.c:
ereport(LOG,
(errcode(ERRCODE_INVALID_REGULAR_EXPRESSION),
errmsg("invalid regular expression \"%s\": %s",
parsedline->ident_user + 1, errstr)));
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. Also, for the principal use-cases in regexp.c,
we could avoid changing the primary message text from what it is now.
That might prevent some unnecessary client breakage (not that people
are supposed to be testing message string contents, but ...)
Thoughts?
regards, tom lane
