Re: More new SQL/JSON item methods

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>

To: Jeevan Chalke <jeevan.chalke@enterprisedb.com>, Peter Eisentraut <peter@eisentraut.org>

Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2024-01-17T16:53:23Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Rationalize and improve error messages for some jsonpath items
- 92d2ab7554f9 17.0 landed
Clean up a bug in sql/json items commit 66ea94e8e6
- 06a66d87dbc7 17.0 landed
Implement various jsonpath methods
- 66ea94e8e606 17.0 cited
Reorganise jsonpath operators and methods
- 283a95da9236 17.0 landed
Add numeric_int8_opt_error() to optionally suppress errors
- c1b9e1e56d8c 17.0 landed

On 2024-01-17 We 04:03, Jeevan Chalke wrote:
>
>
> On Mon, Jan 15, 2024 at 7:41 PM Peter Eisentraut 
> <peter@eisentraut.org> wrote:
>
>
>     Overall, I think it would be better if you combined all three of
>     these
>     patches into one.  Right now, you have arranged these as incremental
>     features, and as a result of that, the additions to the
>     JsonPathItemType
>     enum and the grammar keywords etc. are ordered in the way you
>     worked on
>     these features, I guess.  It would be good to maintain a bit of
>     sanity
>     to put all of this together and order all the enums and everything
>     else
>     for example in the order they are in the sql_features.txt file
>     (which is
>     alphabetical, I suppose).  At this point I suspect we'll end up
>     committing this whole feature set together anyway, so we might as
>     well
>     organize it that way.
>
>
> OK.
> I will merge them all into one and will try to keep them in the order 
> specified in sql_features.txt.
> However, for documentation, it makes more sense to keep them in 
> logical order than the alphabetical one. What are your views on this?
>

I agree that we should order the documentation logically. Users don't 
care how we organize the code etc, but they do care about docs have 
sensible structure.


cheers


andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com