Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rRwVL-00AJHB-7S for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jan 2024 15:46:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rRwVK-004iCU-A1 for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Jan 2024 15:46:30 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rRwVK-004iCJ-0s for pgsql-hackers@lists.postgresql.org; Mon, 22 Jan 2024 15:46:30 +0000 Received: from mail-vs1-xe2c.google.com ([2607:f8b0:4864:20::e2c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rRwVH-002oPH-Dh for pgsql-hackers@postgresql.org; Mon, 22 Jan 2024 15:46:28 +0000 Received: by mail-vs1-xe2c.google.com with SMTP id ada2fe7eead31-4697f2ed1e5so709106137.2 for ; Mon, 22 Jan 2024 07:46:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705938386; x=1706543186; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=b1vOurrujrB1/7Ebr+CpW+OleooJxtUb0C7t3YZUqE8=; b=BqMoPdil4dZDdoyN3X8mqEmvtxR6OZSdqT8C2zLyjUKexeMhWOD3Zo7dbsgeidxJWB uzs2oxosl0EpbMfwX3JgARQsbuPKRikNZf77/CAkhdZyvb/jwPNJYwlKUYFki5AZoqO1 AoDJORuqK1BfYkRZCbS0H2zUz5AZDXBe3DmVfCF27fLZVWOvz1Ms36tbj5Q/NAT5f6Au tACsyDBUflAvr4OC/pq3CP1+Zrcku8Qe8rDr9WtOebcY/dIGgjrLEVD+qBmEDdikhxVU fBEI7FpMXDbYrfQ0IlgMQqZAYIiOgo8/yZIYaxyH5f0k9iXkKO1+OD3XLVglIEdY71AF 6IVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705938386; x=1706543186; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=b1vOurrujrB1/7Ebr+CpW+OleooJxtUb0C7t3YZUqE8=; b=P8awesEgtXT+C87e55NhW1fX0Ga826blJYq6p2gAuqR0UWDs8wuyTF6cNII5Yxz6qm T0UjA+lZzTd2uEtI52BQCjkN1FsvVrkr3sefiOOMa4PmrOfr87eY23ilfNR1Oy+RVvAv f1uudiMBcDtvaWV1wi0DLP5Fs4LDDvLTUOHpeG9TSmOI++o02jzg/JDp/UjSSDt0zzEi iZS9X0qYggV14TQVzuilGbsPiHx1kd21LB2cGPJlr7Ip7pGs55b/bDidHAOCkP1b6qqp QYQcHTIuK7AFgjMiLNA3YBM0MKSwYQBAzExkfTuU3yDabnrHYb7Hh206N/8akVrgqYGi 1wqg== X-Gm-Message-State: AOJu0YwVZafvDRQWrS6Frlrhmr/UODX3iTG6AqyrxJ0pgzspeFnEroIO yP8v7/5nWwuclvYKa7gZOfo62Sk9mStWkyzBlmKaYJOZHk68rpcNph+/syxFBNX2KtgwZnAcIQv AkMp70VYV1j6kMNF4wg39GCsxxRrVhoNGnCsuGX4q X-Google-Smtp-Source: AGHT+IFekWRxAY3PpaU0PRNBRyPY6lyt9EQw+N5p1X5YLZhPemaCeVUao9AK0mfuoFUEF78mUz87MS7shySS6jA+e1A= X-Received: by 2002:a67:b648:0:b0:469:af90:79be with SMTP id e8-20020a67b648000000b00469af9079bemr1279065vsm.8.1705938386662; Mon, 22 Jan 2024 07:46:26 -0800 (PST) MIME-Version: 1.0 References: <202401181146.fuoeskfzriq7@alvherre.pgsql> <202401181711.qxjxpnl3ohnw@alvherre.pgsql> In-Reply-To: From: jian he Date: Mon, 22 Jan 2024 23:46:15 +0800 Message-ID: Subject: Re: remaining sql/json patches To: Amit Langote Cc: Alvaro Herrera , Andres Freund , Erik Rijkers , Andrew Dunstan , PostgreSQL-development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Jan 22, 2024 at 10:28=E2=80=AFPM Amit Langote wrote: > > > based on v35. > > Now I only applied from 0001 to 0007. > > For {DEFAULT expression ON EMPTY} | {DEFAULT expression ON ERROR} > > restrict DEFAULT expression be either Const node or FuncExpr node. > > so these 3 SQL/JSON functions can be used in the btree expression index= . > > I'm not really excited about adding these restrictions into the > transformJsonFuncExpr() path. Index or any other code that wants to > put restrictions already have those in place, no need to add them > here. Moreover, by adding these restrictions, we might end up > preventing users from doing useful things with this like specify > column references. If there are semantic issues with allowing that, > we should discuss them. > after applying v36. The following index creation and query operation works. I am not 100% sure about these cases. just want confirmation, sorry for bothering you.... drop table t; create table t(a jsonb, b int); insert into t select '{"hello":11}',1; insert into t select '{"hello":12}',2; CREATE INDEX t_idx2 ON t (JSON_query(a, '$.hello1' RETURNING int default b + random() on error)); CREATE INDEX t_idx3 ON t (JSON_query(a, '$.hello1' RETURNING int default random()::int on error)); SELECT JSON_query(a, '$.hello1' RETURNING int default ret_setint() on error) from t; SELECT JSON_query(a, '$.hello1' RETURNING int default sum(b) over() on error) from t; SELECT JSON_query(a, '$.hello1' RETURNING int default sum(b) on error) from t group by a; but the following cases will fail related to index and default expression. create table zz(a int, b int); CREATE INDEX zz_idx1 ON zz ( (b + random()::int)); create table ssss(a int, b int default ret_setint()); create table ssss(a int, b int default sum(b) over());