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 1rhpv9-00Dbef-3t for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Mar 2024 11:58:51 +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 1rhpv6-009RuF-M2 for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Mar 2024 11:58:49 +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 1rhpv6-009Ru7-38 for pgsql-hackers@lists.postgresql.org; Wed, 06 Mar 2024 11:58:48 +0000 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rhpv2-0038Of-Hz for pgsql-hackers@postgresql.org; Wed, 06 Mar 2024 11:58:47 +0000 Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a28a6cef709so1074047066b.1 for ; Wed, 06 Mar 2024 03:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709726324; x=1710331124; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bN/QtdhhFMxIjiarKmQ+c1Yu0ABpmhch44f21zmtk+o=; b=g7mF2Ru3eXi2S/6+bsNwM43oinXtOsXsgESnEx9sHH7P0KA0rmPMgSx2WVjzddI5MG j8jQFi8Sh0zze2QdKHPuF4K3ExvsVTfhE0ZwEj9cA5VFJUXe3Yfirapl1vF1CSvcu+/o vgUeNzy7IAuO9gUES0NNBRa1YvaK3ezE9Kj8f1qzI4fxIE7fuG0mhR57llgj0RDnTvGS OKy9oaEJKtSXBwvR6r+iwrZZjodgB5JDQ4L51pw9oEsQwkBxMkwCovyBp7COOIGOW3Db 4Q89cH4owO/oQdkwTvO2WSmb5whu7Nh4BqbObeFdwp9HQBKg5eIQhQ2Kv0hOEuLCKdUu EK9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709726324; x=1710331124; h=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=bN/QtdhhFMxIjiarKmQ+c1Yu0ABpmhch44f21zmtk+o=; b=ZnO9V3yFSChrnumj/gK/ub52q4MnoEtZFgjEfYk5ZYscyjF8olqltFJRfnFOlsGXiy C9bQocsKJn1ujc14M2ji0YKiVPeyaZ3rNz7ujBy7EvP3mElMnsJ9ozpzQfcWryQvrPGa mcWLrZx3Hv7+NK83kirP5xzh42QVyB2SA0O1gqRarnH7/vJgB4QUL1aW90qkh2z2B/iD CS3S9bBH6pwB88JF8bAH0yxpNCfzcUhSrc2+M21/LIoEdN6ywIruZe8TTon+HwBlC0FS zK4Mt+lNBm7sgLytJuxJkIvlXUz13FgNKS9f/oM3vlBqPd6f4iamCa1B+PH6LECysC+z o/Og== X-Forwarded-Encrypted: i=1; AJvYcCW7A70xJI0SGGQe5mB8HgHf7BVW3WChN0Q7ggUASIG7JdwGl2aQCKBvN1w2alsQ26WgCIkak71My3M8iUaqTB+OCV4qXOSKGnj9LKav X-Gm-Message-State: AOJu0YyaJT3aj87z77oBTjaxwDp/qHEjO7PaB6d9B9cjF9c0KxgVS/ld CW8BEPLUZ96DBWrF2VBoRvaraZlx4VGVWCxa6kuUNVu2isYgA45xSvXuoAWv8rIAkgv8xAJBYe3 s/Y0K33MtXNeQ5oqlzv0ElM1zXYQ= X-Google-Smtp-Source: AGHT+IEDIDywegS79TFDm7pDqLFSciTJQTUPDG+lHoLJQ91VRPXlooG6sbbRu8gHJrn708HxMZXPz5zGSymBh0IYOAg= X-Received: by 2002:a17:906:11ce:b0:a44:1fcf:9b9c with SMTP id o14-20020a17090611ce00b00a441fcf9b9cmr9619831eja.51.1709726323933; Wed, 06 Mar 2024 03:58:43 -0800 (PST) MIME-Version: 1.0 References: <1cee81f3-312f-30e3-0282-c4df7ee72f93@xs4all.nl> <202403041503.5momp6knupgo@alvherre.pgsql> In-Reply-To: From: Himanshu Upadhyaya Date: Wed, 6 Mar 2024 17:28:06 +0530 Message-ID: Subject: Re: remaining sql/json patches To: Amit Langote Cc: Alvaro Herrera , Erik Rijkers , jian he , Andres Freund , Andrew Dunstan , PostgreSQL-development Content-Type: multipart/alternative; boundary="000000000000338f0d0612fcae22" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000338f0d0612fcae22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 5, 2024 at 6:52=E2=80=AFAM Amit Langote wrote: Hi, I am doing some random testing with the latest patch and found one scenario that I wanted to share. consider a below case. =E2=80=98postgres[102531]=3D#=E2=80=99SELECT * FROM JSON_TABLE(jsonb '{ "id" : 12345678901, "FULL_NAME" : "JOHN DOE"}', '$' COLUMNS( name varchar(20) PATH 'lax $.FULL_NAME', id int PATH 'lax $.id' ) ) ; ERROR: 22003: integer out of range LOCATION: numeric_int4_opt_error, numeric.c:4385 =E2=80=98postgres[102531]=3D#=E2=80=99SELECT * FROM JSON_TABLE(jsonb '{ "id" : "12345678901", "FULL_NAME" : "JOHN DOE"}', '$' COLUMNS( name varchar(20) PATH 'lax $.FULL_NAME', id int PATH 'lax $.id' ) ) ; name | id ----------+---- JOHN DOE | (1 row) The first query throws an error that the integer is "out of range" and is quite expected but in the second case(when the value is enclosed with ") it is able to process the JSON object but does not return any relevant error(in fact processes the JSON but returns it with empty data for "id" field). I think second query should fail with a similar error. --=20 Regards, Himanshu Upadhyaya EnterpriseDB: http://www.enterprisedb.com --000000000000338f0d0612fcae22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Mar 5, 2024 at 6:52=E2=80=AFAM Am= it Langote <amitlangote09@gma= il.com> wrote:

=
Hi,

I am doing some random testing with the latest patch and found one scenari= o that I wanted to share.
consider a below case.

=E2=80=98postgres[102531]=3D#=E2=80=99SELECT * FROM JSON_TABLE(jso= nb '{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"id" : 12345678901= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"FULL_NAME" : "JOHN D= OE"}',
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = '$'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 COLU= MNS(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0name varchar(20) PATH 'lax $.FULL_NAME',
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0id int PATH = 'lax $.id'
=C2=A0 =C2=A0 =C2=A0 )
=C2=A0 =C2=A0)
;
ERRO= R: =C2=A022003: integer out of range
LOCATION: =C2=A0numeric_int4_opt_er= ror, numeric.c:4385
=E2=80=98postgres[102531]=3D#=E2=80=99SELECT * FROM = JSON_TABLE(jsonb '{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"id"= : "12345678901",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"FULL= _NAME" : "JOHN DOE"}',
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 '$'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 COLUMNS(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0name varchar(20) PATH 'lax $.FULL= _NAME',
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0id int PATH 'lax $.id'
=C2=A0 =C2=A0 =C2=A0 )=C2=A0 =C2=A0)
;
=C2=A0 =C2=A0name =C2=A0 | id
----------+----<= br>=C2=A0JOHN DOE | =C2=A0
(1 row)

The first q= uery throws an error that the integer is "out of range" and is qu= ite expected but in the second case(when the value is enclosed with ")= it is able to process the JSON object but does not return any relevant err= or(in fact processes the JSON but returns it with empty data for "id&q= uot; field). I think second query should fail with a similar error.


--
Regards, Himanshu Upadhyaya
EnterpriseDB: http://www.enterprisedb.com
--000000000000338f0d0612fcae22--