Re: Define jsonpath functions as stable
Jonathan S. Katz <jkatz@postgresql.org>
From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>,
Chapman Flack <chap@anastigmatix.net>, Erik Rijkers <er@xs4all.nl>,
pgsql-hackers@lists.postgresql.org
Date: 2019-09-19T22:20:16Z
Lists: pgsql-hackers
On 9/19/19 6:18 PM, Tom Lane wrote: > "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. Great. +1 on that. > 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. +100 on that. Jonathan
Commits
-
Fix some minor spec-compliance issues in jsonpath lexer.
- e56cad84d542 13.0 landed
- 5f3bec0769c1 12.0 landed
-
Doc: improve documentation around jsonpath regular expressions.
- b9cf94c8c249 12.0 landed
- 0a97edb12ec4 13.0 landed
-
Fix bogus handling of XQuery regex option flags.
- d5b90cd64855 13.0 landed
- 148881454208 12.0 landed