Re: [HACKERS] [PATCH] Generic type subscripting

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] [PATCH] Generic type subscripting
Дата
Msg-id CAFj8pRBhHabV06m_-n6qjmR-BQC=+t740EJs4Gu5Ck0jzNQMhQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Generic type subscripting  (Dmitry Dolgov <9erthalion6@gmail.com>)
Ответы Re: [HACKERS] [PATCH] Generic type subscripting  (Dmitry Dolgov <9erthalion6@gmail.com>)
Список pgsql-hackers


st 29. 5. 2019 v 17:49 odesílatel Dmitry Dolgov <9erthalion6@gmail.com> napsal:
Rebase after pg_indent. Besides, off the list there was a suggestion that this
could be useful to accept more than one data type as a key for subscripting.
E.g. for jsonb it probably makes sense to understand both a simple key name and
jsonpath:

    jsonb['a'] and jsonb['$.a']

While to implement it can be technically relatively straightforward I guess, I
wonder if there is any opinion about how valuable it could be and what it
should looks like from the syntax point of view (since I believe a user needs
to specify which type needs to be used).

It is difficult decision - possibility to use jsonpath looks great, but necessity to cast every time is not friendly.

Probably there can be preferred type if subscripting is of unknown type. There can be similar rules to function's parameters.

so jsonb['a'] -- key
    jsonb['$.a'] -- key
    jsonb['$.a'::jsonpath'] -- json path

but it can be source of bad issues - so I think we don't need this feature in this moment. This feature can be implemented later, I think.

Regards

Pavel


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: incorrect xlog.c coverage report
Следующее
От: Dave Cramer
Дата:
Сообщение: Re: [HACKERS] Built-in plugin for logical decoding output