Horton

Re: PG 12 draft release notes

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Oleg Bartunov <obartunov@postgrespro.ru>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, Alexander Korotkov <aekorotkov@gmail.com>
Date: 2019-05-14T02:23:05Z
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 →

  1. doc: PG 12 relnotes: update wording on truncate/vacuum item

  2. docs: PG 12 relnotes, update btree items

  3. doc: PG 12 relnotes, list added snowball/FTS languages

  4. doc: PG 12 relnotes, merge new SQL partition function items

  5. docs: PG 12 release notes, support functions

  6. docs: PG 12 relnote adjustments based on feedback from Tom Lane

  7. docs: adjust RECORD PG 12 relnote item

  8. doc: adjust PG 12 relnotes item on float digit adjustment

  9. doc: adjustments for PG 12 release notes

  10. docs: fix duplicate wording in PG 12 release notes

  11. doc: properly attibute PG 12 pgbench release note item

  12. doc: PG 12 release notes: normalize attribution names

  13. Refactor the fsync queue for wider use.

  14. Add "split after new tuple" nbtree optimization.

  15. Add nbtree high key "continuescan" optimization.

  16. Allow amcheck to re-find tuples using new search.

  17. Consider secondary factors during nbtree splits.

  18. Partial implementation of SQL/JSON path language

  19. Allow extensions to generate lossy index conditions.

  20. Make TupleTableSlots extensible, finish split of existing slot type.

  21. Reduce path length for locking leaf B-tree pages during insertion

On Mon, May 13, 2019 at 10:08:57AM +0300, Oleg Bartunov wrote:
> On Mon, May 13, 2019 at 6:52 AM Bruce Momjian <bruce@momjian.us> wrote:
> >
> > On Sun, May 12, 2019 at 09:49:40AM -0400, Bruce Momjian wrote:
> > > On Sun, May 12, 2019 at 10:00:38AM +0300, Oleg Bartunov wrote:
> > > > Bruce,
> > > >
> > > > I noticed that jsonpath in your version is mentioned only in functions
> > > > chapter, but  commit
> > > > 72b6460336e86ad5cafd3426af6013c7d8457367 is about implementation of
> > > > SQL-2016 standard. We implemented JSON Path language as a jsonpath
> > > > datatype with a bunch of support functions, our implementation
> > > > supports 14 out of 15 features and it's the most complete
> > > > implementation (we compared oracle, mysql and ms sql).
> > >
> > > Glad you asked.  I was very confused about why a data type was added for
> > > a new path syntax.  Is it a new storage format for JSON, or something
> > > else?  I need help on this.
> >
> > I talked to Alexander Korotkov on chat about this.  The data types are
> > used as arguments to the functions, similar to how tsquery and tsvector
> > are used for full text search.
> >
> > Therefore, the data types are not really useful on their own, but as
> > support for path functions.  However, path functions are more like JSON
> > queries, rather than traditional functions, so it odd to list them under
> > functions, but there isn't a more reasonable place to put them.
> >
> > Alexander researched how we listed full text search in the release notes
> > that added the feature, but we had  "General" category at that time that
> > we don't have now.
> 
> I attached slide about our Jsonpath implementation in Postgres, it
> summarizes the reasons to have jsonpath data type. But my point was:
> JSON Path is a part of SQL-2016 standard and I think it's worth to
> mention it, not just a set of jsonb functions.

So, are you suggesting we mention the jsonpath data type in the Data
Type section, even though it is useless without jsonpath, which is in
another section, or are you suggesting to move the jsonpath item to the
Data Type section?

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +