Re: Problems with Error Messages wrt Domains, Checks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: john frazer <johnfrazer783(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Problems with Error Messages wrt Domains, Checks
Date: 2018-03-19 15:33:12
Message-ID: 31804.1521473592@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-03-19 15:38:32 Re: inserts into partitioned table may cause crash
Previous Message Claudio Freire 2018-03-19 15:06:38 Re: Faster inserts with mostly-monotonically increasing values