Re: Problems with Error Messages wrt Domains, Checks

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Problems with Error Messages wrt Domains, Checks
Дата
Msg-id 31804.1521473592@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Problems with Error Messages wrt Domains, Checks  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: Problems with Error Messages wrt Domains, Checks  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Problems with Error Messages wrt Domains, Checks  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-hackers
"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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: Faster inserts with mostly-monotonically increasing values
Следующее
От: Robert Haas
Дата:
Сообщение: Re: inserts into partitioned table may cause crash