Re: jsonpath

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Andres Freund <andres(at)anarazel(dot)de>
Cc: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Oleg Bartunov <obartunov(at)postgrespro(dot)ru>, Michael Paquier <michael(at)paquier(dot)xyz>, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, David Steele <david(at)pgmasters(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Subject: Re: jsonpath
Date: 2019-02-24 11:44:46
Message-ID: 957ee2ff-f9a6-0ba1-13e2-9c4d320f63ac@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2/24/19 10:03 AM, Alexander Korotkov wrote:
> Hi!
>
> Attached is revised version of jsonpath. Assuming that jsonpath have
> problem places, I decided to propose partial implementation.
> Following functionality was cut from jsonpath:
> 1) Support of datetime datatypes. Besides error suppression, this
> functionality have troubles with timezones. According to standard we
> should support timezones in jsonpath expressions. But that would
> prevent jsonpath functions from being immutable, that in turn limits
> their usage in expression indexes.

Assuming we get the patch committed without the datetime stuff now, what
does that mean for the future? Does that mean we'll be unable to extend
it to support datetime in the future, or what? If we define the jsonpath
functions as immutable now, people may create indexes - which means we
won't be able to downgrade it to stable later.

So, what's the plan here? The only thing I can think of is having two
sets of functions - an immutable one, prohibiting datetime expressions,
and stable that can't be used for indexes etc.

> 2) Suppression of numeric errors. I will post it as a separate patch.
> Pushing this even this partial implementation of jsonpath to PG 12 is
> still very useful. Also it will simplify a lot pushing other parts of
> SQL/JSON to future releases.
>

+1 to push at least partial (but still useful) subset, instead of just
bumping the patch to PG13

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

  • Re: jsonpath at 2019-02-24 09:03:19 from Alexander Korotkov

Responses

  • Re: jsonpath at 2019-02-24 12:34:22 from Alexander Korotkov

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2019-02-24 12:34:22 Re: jsonpath
Previous Message Dmitry Belyavsky 2019-02-24 11:31:55 Re: Ltree syntax improvement