Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h0VX3-0000Jz-P8 for pgsql-hackers@arkaria.postgresql.org; Sun, 03 Mar 2019 18:08:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h0VX0-0001gW-Rh for pgsql-hackers@arkaria.postgresql.org; Sun, 03 Mar 2019 18:08:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h0VX0-0001fV-Ds for pgsql-hackers@lists.postgresql.org; Sun, 03 Mar 2019 18:08:10 +0000 Received: from mail-wm1-x341.google.com ([2a00:1450:4864:20::341]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h0VWw-0003ZL-Ke for pgsql-hackers@postgresql.org; Sun, 03 Mar 2019 18:08:09 +0000 Received: by mail-wm1-x341.google.com with SMTP id a188so2562518wmf.3 for ; Sun, 03 Mar 2019 10:08:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4APAT8UQ+NIFPXaORXnvSC+f5t9PsGw542TlMDf/YX4=; b=y84fL0DqTXiG7ZnQca0IyjGUD3tgnaZBipLt/f88/98Y3h6b1m517OFZ5aCr1AizaP DEsWeyAGdNhkiDkNVHEFFeycjA/JF2ewgZbjDMKOvlD2/bFJKCJc0FYjFGkNZoYEWOyu d7AUx0RP8oa4rvjRQ1MhHASy6MNkBlFLnWw1caorsF+nh/LiHz+5PYIgmehxIWMgVklW hQZJ/26CQ+NgSAWHoLmEAOfWCPQABhdN/1yrBO+ylqNrAIvKtohV67L6WuGgGKF2hmXp 2jYk4I8epBJwPCqUxp4cnmTu0jAcza9BFEZex4OYLDXSVxbsg0IpzJvm7ieYK3qZhfW2 Br3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4APAT8UQ+NIFPXaORXnvSC+f5t9PsGw542TlMDf/YX4=; b=I9O8p09Lpyx0bfbeqawK9Kde4AcwcM6rof2b+ca/74NY2gKhu4LWwTwsNdUlFIuZB1 LPatnDJ2GijSyh/SVzA+ca1TVHGm3ZpPe8LSJ5ydhaLxVrA7kb5cXahXWnMlsauqOgf/ aXDnXhilYAuBfDvtMc62plIfCcTY7A8EzMRTVsmVyYjW6ranOexhv6Y8VLQIIwEMfh1L qH1vHd0JtEfht4W+e6xweZIUy10ijiay7F+15Cpz6R4S6eUcyJuzxxF2t9j9BWRSe9TK ryQ2HCLpLf23aYReXlkKH8lObZEy8yHZmqaVjRziaUIEOr9KUZjx4/Q6+zBXHVMolbr8 OK2w== X-Gm-Message-State: AHQUAuZdc0BUyNkz63JfHvyx5yvEu7wiEuhSvMXgqgRA+Hv5OhiZjESG p59YGz7rm6HWQsXj5sPS61HHTg== X-Google-Smtp-Source: APXvYqylArfMSABth5lIZyfAVIAA1UtG+wOM1BM4yJmG7Y48yWrv5hNISES32ntnxDfp1nXkiqAVtQ== X-Received: by 2002:a1c:eb1a:: with SMTP id j26mr8555219wmh.43.1551636485452; Sun, 03 Mar 2019 10:08:05 -0800 (PST) Received: from [10.137.0.17] (ip-86-49-253-226.net.upcbroadband.cz. [86.49.253.226]) by smtp.gmail.com with ESMTPSA id i12sm5279316wrq.21.2019.03.03.10.08.03 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sun, 03 Mar 2019 10:08:04 -0800 (PST) Subject: Re: jsonpath To: Alexander Korotkov , Nikita Glukhov Cc: Andres Freund , Oleg Bartunov , Michael Paquier , Stas Kelvich , PostgreSQL-development , Thomas Munro , David Steele , Tom Lane , Andrew Dunstan , Robert Haas , Pavel Stehule References: <264a6413-7175-9680-b976-d50392c001c0@postgrespro.ru> <9f5f1247-29f4-17cd-edd9-38e9bcd95b14@postgrespro.ru> <20190130022826.of7w6xv5lbvzqxfp@alap3.anarazel.de> <957ee2ff-f9a6-0ba1-13e2-9c4d320f63ac@2ndquadrant.com> From: Tomas Vondra Message-ID: Date: Sun, 3 Mar 2019 19:08:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, Here are some initial comments from a review of the 0001 part. I plan to do more testing on a large data set and additional round of review over the next week. FWIW I've passed this through valgrind and the usual battery of regression tests, and there were no issues. I haven't looked at 0002 yet, but it seems fairly small (especially compared to 0001). func.sgml ========= 1) I see the changes removed for some reason. Is that intentional? 2) WHERE We generally tag WHERE, not . 3) Filter expressions are applied from left to right Perhaps s/applied/evaluated/ in reference to expressions? 4) The result of the filter expression may be true, false, or unknown. It's not entirely clear to me what "unknown" means here. NULL, or something else? There's a section in the SQL/JSON standard explaining this (page 83), but perhaps we should explain it a bit here too? The standard says "In the SQL/JSON data model, there are no SQL nulls, so Unknown is not part of the SQL/JSON data model." so I'm a bit confused what "unknown" references to. Maybe some example? Also, what happens when the result is unknown? 5) There's an example showing how to apply filter at a certain level, using the @ variable, but what if we want to apply multiple filters at different levels? Would it make sense to add such example? 6) ... extensions of the SQL/JSON standard I'm not sure what "extension" is here. Is that an extension defined in the SQL standard, or an additional PostgreSQL functionality not described in the standard? (I assume the latter, just checking.) 7) There are references to "SQL/JSON sequences" without any explanation what it means. Maybe I'm missing something obvious, though. 8) Implicit unwrapping in the lax mode is not performed in the following cases: I suggest to reword it like this: In the lax mode, implicit unwrapping is not performed when: 9) We're not adding the datetime() method for now, due to the issues with timezones. I wonder if we should add a note why it's missing to the docs ... 10) I'm a bit puzzled though, because the standard says this in the description of type() function on page 77 If I is a datetime, then “date”, “time without time zone”, “time with time zone”, “timestamp without time zone”, or “timestamp with time zone”, as appropriate. But I see our type() function does not return anything like that (which I presume is independent of timezone stuff). But I see jsonb.h has no concept of datetime values, and the standard actually says this in the datetime() section JSON has no datetime types. Datetime values are most likely stored in character strings. Considering this, the type() section makes little sense, no? jsonb_util.c ============ I see we're now handling NaN values in convertJsonbScalar(). Isn't it actually a bug that we don't do this already? Or is it not needed for some reason? jsonpath.c ========== I suppose this should say "jsonpath version number" instead? elog(ERROR, "unsupported jsonb version number %d", version); regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services