Re: Define jsonpath functions as stable - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Define jsonpath functions as stable
Date
Msg-id 17038.1568931530@sss.pgh.pa.us
Whole thread Raw
In response to Re: Define jsonpath functions as stable  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Responses Re: Define jsonpath functions as stable
List pgsql-hackers
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 9/19/19 3:48 PM, Tom Lane wrote:
>> Seems like
>> the error handling in jsonpath_gram.y could use some cleanup too
>> ... although I don't think it's a task to tackle while we're
>> rushing to get v12 shippable.

> IIRC if we want to change the contents of an error message we wait until
> major releases. Is there anything we can do before 12 to avoid messages
> like "unexpected IDENT_P" coming to a user? Would that be something
> acceptable to fix as a 12.1 or would it have to wait until 13?

I think these messages are sufficiently confusing that we could call
it a bug fix to improve them.  As long as we don't change the SQLSTATE
that's thrown, it's hard to claim that there's any real application
compatibility hazard from changing them.

I just don't want to call this point a release blocker.  It's not
about changing any semantics or the set of things that work.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: Re: Define jsonpath functions as stable
Next
From: "Jonathan S. Katz"
Date:
Subject: Re: Define jsonpath functions as stable