public inbox for [email protected]  
help / color / mirror / Atom feed
[PATCH 6/8] Default to LZ4..
6+ messages / 5 participants
[nested] [flat]

* [PATCH 6/8] Default to LZ4..
@ 2021-03-12 21:35  Justin Pryzby <[email protected]>
  0 siblings, 0 replies; 6+ messages in thread

From: Justin Pryzby @ 2021-03-12 21:35 UTC (permalink / raw)

this is meant to exercise in the CIs, and not meant to be merged
---
 configure                    | 6 ++++--
 configure.ac                 | 4 ++--
 src/backend/utils/misc/guc.c | 2 +-
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 9b590eb432..3afa1e87e3 100755
--- a/configure
+++ b/configure
@@ -1575,7 +1575,7 @@ Optional Packages:
   --with-system-tzdata=DIR
                           use system time zone data in DIR
   --without-zlib          do not use Zlib
-  --with-lz4              build with LZ4 support
+  --without-lz4           build without LZ4 support
   --with-gnu-ld           assume the C compiler uses GNU ld [default=no]
   --with-ssl=LIB          use LIB for SSL/TLS support (openssl)
   --with-openssl          obsolete spelling of --with-ssl=openssl
@@ -8598,7 +8598,9 @@ $as_echo "#define USE_LZ4 1" >>confdefs.h
   esac
 
 else
-  with_lz4=no
+  with_lz4=yes
+
+$as_echo "#define USE_LZ4 1" >>confdefs.h
 
 fi
 
diff --git a/configure.ac b/configure.ac
index 2b3b5676eb..d62ea5f742 100644
--- a/configure.ac
+++ b/configure.ac
@@ -990,8 +990,8 @@ AC_SUBST(with_zlib)
 # LZ4
 #
 AC_MSG_CHECKING([whether to build with LZ4 support])
-PGAC_ARG_BOOL(with, lz4, no, [build with LZ4 support],
-              [AC_DEFINE([USE_LZ4], 1, [Define to 1 to build with LZ4 support. (--with-lz4)])])
+PGAC_ARG_BOOL(with, lz4, yes, [build without LZ4 support],
+              [AC_DEFINE([USE_LZ4], 1, [Define to 1 to build without LZ4 support. (--without-lz4)])])
 AC_MSG_RESULT([$with_lz4])
 AC_SUBST(with_lz4)
 
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index c37a8313d3..52f9cd0242 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -4728,7 +4728,7 @@ static struct config_enum ConfigureNamesEnum[] =
 			NULL
 		},
 		&wal_compression_method,
-		WAL_COMPRESSION_ZLIB, wal_compression_options,
+		WAL_COMPRESSION_LZ4, wal_compression_options,
 		NULL, NULL, NULL
 	},
 
-- 
2.17.0


--f0KYrhQ4vYSV2aJu
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
 filename="0007-add-wal_compression_method-zstd.patch"



^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: remaining sql/json patches
@ 2024-03-11 15:34  Alvaro Herrera <[email protected]>
  0 siblings, 1 reply; 6+ messages in thread

From: Alvaro Herrera @ 2024-03-11 15:34 UTC (permalink / raw)
  To: Shruthi Gowda <[email protected]>; +Cc: jian he <[email protected]>; Amit Langote <[email protected]>; Andres Freund <[email protected]>; Andrew Dunstan <[email protected]>; Erik Rijkers <[email protected]>; pgsql-hackers; Tomas Vondra <[email protected]>

On 2024-Mar-11, Shruthi Gowda wrote:

> *CASE 2:*
> ------------------
> SELECT * FROM JSON_TABLE(jsonb '{
>          "id" : 901,
>          "age" : 30,
>          "*FULL_NAME*" : "KATE DANIEL"}',
>                 '$'
>                 COLUMNS(
>                      FULL_NAME varchar(20),
>                      ID int,
>                      AGE int
>       )
>    ) as t;

I think this is expected: when you use FULL_NAME as a SQL identifier, it
is down-cased, so it no longer matches the uppercase identifier in the
JSON data.  You'd have to do it like this:

SELECT * FROM JSON_TABLE(jsonb '{
         "id" : 901,
         "age" : 30,
         "*FULL_NAME*" : "KATE DANIEL"}',
                '$'
                COLUMNS(
                     "FULL_NAME" varchar(20),
                     ID int,
                     AGE int
      )
   ) as t;

so that the SQL identifier is not downcased.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/






^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: remaining sql/json patches
@ 2024-03-11 19:07  Shruthi Gowda <[email protected]>
  parent: Alvaro Herrera <[email protected]>
  0 siblings, 1 reply; 6+ messages in thread

From: Shruthi Gowda @ 2024-03-11 19:07 UTC (permalink / raw)
  To: Alvaro Herrera <[email protected]>; +Cc: jian he <[email protected]>; Amit Langote <[email protected]>; Andres Freund <[email protected]>; Andrew Dunstan <[email protected]>; Erik Rijkers <[email protected]>; pgsql-hackers; Tomas Vondra <[email protected]>

Thanka Alvaro. It works fine when quotes are used around the column name.

On Mon, Mar 11, 2024 at 9:04 PM Alvaro Herrera <[email protected]>
wrote:

> On 2024-Mar-11, Shruthi Gowda wrote:
>
> > *CASE 2:*
> > ------------------
> > SELECT * FROM JSON_TABLE(jsonb '{
> >          "id" : 901,
> >          "age" : 30,
> >          "*FULL_NAME*" : "KATE DANIEL"}',
> >                 '$'
> >                 COLUMNS(
> >                      FULL_NAME varchar(20),
> >                      ID int,
> >                      AGE int
> >       )
> >    ) as t;
>
> I think this is expected: when you use FULL_NAME as a SQL identifier, it
> is down-cased, so it no longer matches the uppercase identifier in the
> JSON data.  You'd have to do it like this:
>
> SELECT * FROM JSON_TABLE(jsonb '{
>          "id" : 901,
>          "age" : 30,
>          "*FULL_NAME*" : "KATE DANIEL"}',
>                 '$'
>                 COLUMNS(
>                      "FULL_NAME" varchar(20),
>                      ID int,
>                      AGE int
>       )
>    ) as t;
>
> so that the SQL identifier is not downcased.
>
> --
> Álvaro Herrera         PostgreSQL Developer  —
> https://www.EnterpriseDB.com/
>


^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: remaining sql/json patches
@ 2024-03-12 09:41  Himanshu Upadhyaya <[email protected]>
  parent: Shruthi Gowda <[email protected]>
  0 siblings, 1 reply; 6+ messages in thread

From: Himanshu Upadhyaya @ 2024-03-12 09:41 UTC (permalink / raw)
  To: Alvaro Herrera <[email protected]>; Amit Langote <[email protected]>; +Cc: jian he <[email protected]>; Andres Freund <[email protected]>; Andrew Dunstan <[email protected]>; Erik Rijkers <[email protected]>; pgsql-hackers; Tomas Vondra <[email protected]>

Hi,

wanted to share the below case:

‘postgres[146443]=#’SELECT JSON_EXISTS(jsonb '{"customer_name": "test",
"salary":1000, "department_id":1}', '$.* ? (@== $dept_id && @ == $sal)'
PASSING 1000 AS sal, 1 as dept_id);
 json_exists
-------------
 f
(1 row)

isn't it supposed to return "true" as json in input is matching with both
the condition dept_id and salary?

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


^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: remaining sql/json patches
@ 2024-03-12 12:07  Amit Langote <[email protected]>
  parent: Himanshu Upadhyaya <[email protected]>
  0 siblings, 1 reply; 6+ messages in thread

From: Amit Langote @ 2024-03-12 12:07 UTC (permalink / raw)
  To: Himanshu Upadhyaya <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; jian he <[email protected]>; Andres Freund <[email protected]>; Andrew Dunstan <[email protected]>; Erik Rijkers <[email protected]>; pgsql-hackers; Tomas Vondra <[email protected]>

Hi Himanshu,

On Tue, Mar 12, 2024 at 6:42 PM Himanshu Upadhyaya
<[email protected]> wrote:
>
> Hi,
>
> wanted to share the below case:
>
> ‘postgres[146443]=#’SELECT JSON_EXISTS(jsonb '{"customer_name": "test", "salary":1000, "department_id":1}', '$.* ? (@== $dept_id && @ == $sal)' PASSING 1000 AS sal, 1 as dept_id);
>  json_exists
> -------------
>  f
> (1 row)
>
> isn't it supposed to return "true" as json in input is matching with both the condition dept_id and salary?

I think you meant to use || in your condition, not &&, because 1000 != 1.

See:

SELECT JSON_EXISTS(jsonb '{"customer_name": "test", "salary":1000,
"department_id":1}', '$.* ? (@ == $dept_id || @ == $sal)' PASSING 1000
AS sal, 1 as dept_id);
 json_exists
-------------
 t
(1 row)

Or you could've written the query as:

SELECT JSON_EXISTS(jsonb '{"customer_name": "test", "salary":1000,
"department_id":1}', '$ ? (@.department_id == $dept_id && @.salary ==
$sal)' PASSING 1000 AS sal, 1 as dept_id);
 json_exists
-------------
 t
(1 row)

Does that make sense?

In any case, JSON_EXISTS() added by the patch here returns whatever
the jsonpath executor returns.  The latter is not touched by this
patch.  PASSING args, which this patch adds, seem to be working
correctly too.

-- 
Thanks, Amit Langote






^ permalink  raw  reply  [nested|flat] 6+ messages in thread

* Re: remaining sql/json patches
@ 2024-03-13 04:19  Himanshu Upadhyaya <[email protected]>
  parent: Amit Langote <[email protected]>
  0 siblings, 0 replies; 6+ messages in thread

From: Himanshu Upadhyaya @ 2024-03-13 04:19 UTC (permalink / raw)
  To: Amit Langote <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; jian he <[email protected]>; Andres Freund <[email protected]>; Andrew Dunstan <[email protected]>; Erik Rijkers <[email protected]>; pgsql-hackers; Tomas Vondra <[email protected]>

On Tue, Mar 12, 2024 at 5:37 PM Amit Langote <[email protected]>
wrote:

>
>
> SELECT JSON_EXISTS(jsonb '{"customer_name": "test", "salary":1000,
> "department_id":1}', '$ ? (@.department_id == $dept_id && @.salary ==
> $sal)' PASSING 1000 AS sal, 1 as dept_id);
>  json_exists
> -------------
>  t
> (1 row)
>
> Does that make sense?
>
> Yes, got it. Thanks for the clarification.

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


^ permalink  raw  reply  [nested|flat] 6+ messages in thread


end of thread, other threads:[~2024-03-13 04:19 UTC | newest]

Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-03-12 21:35 [PATCH 6/8] Default to LZ4.. Justin Pryzby <[email protected]>
2024-03-11 15:34 Re: remaining sql/json patches Alvaro Herrera <[email protected]>
2024-03-11 19:07 ` Re: remaining sql/json patches Shruthi Gowda <[email protected]>
2024-03-12 09:41   ` Re: remaining sql/json patches Himanshu Upadhyaya <[email protected]>
2024-03-12 12:07     ` Re: remaining sql/json patches Amit Langote <[email protected]>
2024-03-13 04:19       ` Re: remaining sql/json patches Himanshu Upadhyaya <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox