Re: jsonpath

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: jsonpath
Дата
Msg-id 20190422003121.GA21711@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: jsonpath  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Список pgsql-hackers
On 2019-Apr-22, Alexander Korotkov wrote:

> Hi!
> 
> Thank you for your review!
> 
> On Mon, Apr 22, 2019 at 1:39 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> >                 RETURN_ERROR(ereport(ERROR,
> >                                      (errcode(ERRCODE_JSON_ARRAY_NOT_FOUND),
> >                                       errmsg(ERRMSG_JSON_ARRAY_NOT_FOUND),
> >                                       errdetail("Jsonpath wildcard array accessor "
> >
> > In the first place, I'm not certain that this will result in the error
> > message being translatable --- do the gettext tools know how to expand
> > macros?
> >
> > In the second place, the actual strings are just restatements of their
> > ERRMSG macro names, which IMO is not conformant to our message style,
> > but it's too hard to see that from source code like this.  Also this
> > style is pretty unworkable/unfriendly if the message needs to contain
> > any %-markers, so I suspect that having a coding style like this may be
> > discouraging you from providing values in places where it'd be helpful to
> > do so.  What I actually see happening as a consequence of this approach is
> > that you're pushing the useful information off to an errdetail, which is
> > not really helpful and it's not per project style either.  The idea is to
> > make the primary message as helpful as possible without being long, not
> > to make it a simple restatement of the SQLSTATE that nobody can understand
> > without also looking at the errdetail.
> >
> > In the third place, this makes it hard for people to grep for occurrences
> > of an error string in our source code.
> >
> > And in the fourth place, we don't do this elsewhere; it does not help
> > anybody for jsonpath to invent its own coding conventions that are unlike
> > the rest of Postgres.
> 
> Just to clarify things.  Do you propose to get rid of RETURN_ERROR()
> macro by expanding it at every occurrence?  Or do you have other ideas
> in the mind?

I think he's not talking about the RETURN_ERROR macro, but about the
ERRMSG_JSON_ARRAY_NOT_FOUND macro.  The PG convention is to repeat the
message literal in every place instead of defining a macro with the
literal.  But at the same time, using the same errmsg() and only vary
the errdetail() is unhelpful, so we want most detail in the errmsg
instead; I think it'd be something like this:

ereport(ERROR,
    (errcode(ERRCODE_JSON_ARRAY_NOT_FOUND),
     errmsg("%s wildcard array accessor not found", "jsonpath")));

note I put the type name "jsonpath" in a separate literal, so that only
the interesting part is seen by translators.

I don't think Tom said anything about the RETURN_ERROR macro.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: jsonpath
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Thoughts on nbtree with logical/varwidth table identifiers, v12on-disk representation