Re: Tackling JsonPath support

Поиск
Список
Период
Сортировка
От Christian Convey
Тема Re: Tackling JsonPath support
Дата
Msg-id CAPfS4ZwgHT5FkRm8LE0ucG97e36ziBm0Pc-GkyGC15ksTwVFpw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Tackling JsonPath support  (Nico Williams <nico@cryptonector.com>)
Ответы Re: Tackling JsonPath support
Re: Tackling JsonPath support
Список pgsql-hackers
On Mon, Nov 28, 2016 at 11:23 AM, Nico Williams <nico@cryptonector.com> wrote:
...
JSON Path is not expressive enough (last I looked) and can be mapped
onto jq if need be anyways.

​Hi Nico,

Could you please clarify what you mean by "not expressive enough"?

I ask because I've been struggling to identify clear requirements for the json-path functionality I'm trying to provide.  It sounds like perhaps you have something concrete in mind.

Since I myself have no need currently for this functionality, I'm left guessing about hypothetical users of it.​  My current mental model is:

(a) Backend web developers.  AFAICT, their community has mostly settled on the syntax/semantics proposed by Stefan Groessner.  It would probably be unkind for PG's implementation to deviate from that without a good reason.

(b) PG hackers who will eventually implement the ISO SQL standard operators.  In the standards-committee meeting notes I've seen, it seemed to me that they were planning to define some operators in terms of json-path expression.  So it would probably be good if whatever json-path function I implement turns out to comply with that standard, so that the PG-hackers can use it as a building block for their work.

(c) Pavel.  (I'm still somewhat unclear on what has him interested in this, and what his specific constraints are.)

- Christian

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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: Fix comment in build_simple_rel
Следующее
От: Tom Lane
Дата:
Сообщение: Corner-case improvement to eqjoinsel_semi