It has it, but the syntax is different:

    SELECT t->'j'->'foo'->'bar'->2, ... FROM tbl t ...

I think SQLite now also supports this syntax.

I would not call “has similar features with a completely incompatible syntax” “having it”.

After all if that’s your benchmark every database with a TEXT type already has T081.

Sort of.

The syntax is different, but close.

SQL 2023: SELECT a.key

PostgreSQL 9.3: SELECT a->'key'

PostgreSQL 14: SELECT a['key']

I've always disliked the postgres JSON syntax.

Don't get me wrong - I love the feature and use it a lot, but I find the syntax awkward and honestly just... strange (though I've not researched it and have no idea of the reasoning behind it).

Will postgres adopt the SQL standard for JSON "simplified accessor" syntax? Has there been any statements or communications from the development team?

> Don't get me wrong - I love the feature and use it a lot, but I find the syntax awkward and honestly just... strange (though I've not researched it and have no idea of the reasoning behind it).

I'm pretty sure the syntax was just reused from hstore (https://www.postgresql.org/docs/current/hstore.html), for familiarity and simplicity. hstore predates json by 4-5 years.

It might also have made expressions easier to parse, as it doesn't conflict with normal identifier access.

Not sure if Postgres has it, but last time I was using TimescaleDB I've written my own functions in Rust and it wasn't hard at all. I've heard it became even easier recently with PL/Rust https://news.ycombinator.com/item?id=35501065

"Not sure if Postures has it, but for a totally unrelated database I wrote my own implementation in a famously finicky, but powerful language."

Made worse by “it” specifically not being a function, that’s the entire point. It’s already available behind a function and a stringly-typed path.