From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Chapman Flack <chap(at)anastigmatix(dot)net>, Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Define jsonpath functions as stable |
Date: | 2019-09-19 22:18:50 |
Message-ID: | 17038.1568931530@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Jonathan S. Katz" <jkatz(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2019-09-19 22:20:16 | Re: Define jsonpath functions as stable |
Previous Message | Jonathan S. Katz | 2019-09-19 22:04:02 | Re: Define jsonpath functions as stable |