Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pmjKZ-0007HM-TD for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Apr 2023 22:52:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pmjKY-0005To-QT for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Apr 2023 22:52:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pmjKY-0005TE-D0 for pgsql-hackers@lists.postgresql.org; Wed, 12 Apr 2023 22:52:46 +0000 Received: from mail-io1-xd2c.google.com ([2607:f8b0:4864:20::d2c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pmjKV-0005qW-LY for pgsql-hackers@lists.postgresql.org; Wed, 12 Apr 2023 22:52:45 +0000 Received: by mail-io1-xd2c.google.com with SMTP id e18so408368iow.3 for ; Wed, 12 Apr 2023 15:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20221208.gappssmtp.com; s=20221208; t=1681339963; x=1683931963; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=RJBn77u+qIXMXMmD7x1ddBqikaqMUdVmtsrckvxSC2Y=; b=1mRgIaGXQ6Wh1f0si4GkAE9Nxuuh7Q5QF43cITd/6K2ud0+bNim6+jUDALY4Q3w0s/ dnZ3Gz2QieOtAev4vDA9UCJ7QAKD4ZysRKzoi1aYuzVYPSNRenBmI/Et1sL+5+ARKzH8 HhaYjgg6HJMI9ux1NSamiN51406BHaeZp+tNQbjwQjrfe65S8lZTRvFHIl08RSFV0hWu nKFI88cajo1QL0i67FmTBuKWkFxx/prBCX74NwDKXdbCwghfWx32xcDxl8sjySKx7upY goGl38AibES1FL/lFiwaaVV8iW+KhMqgIm6OJ0fzZK0/WTOveMlkkql+r6BfnLQGwaY8 IZkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681339963; x=1683931963; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RJBn77u+qIXMXMmD7x1ddBqikaqMUdVmtsrckvxSC2Y=; b=QQ1RZNRWHDAxdyxBS7GV3R1rZcHxzbELtca2lusmYmg7pmYpu8vBIiphiv/QIXQBsK 3LA6iFjhYR6hnkYQ7VvBpbFiraiaEkM+DyJSS05jbb1w8st+nJmHzKzCb1xS4R5dBigg VIpKQqu/ncvdqWeWIr/ZHdUQHSc2FuOjxIUdhcSIp1OAWARQlwoY0o2pYZSrVxL7zZbi /I9Qwy+ISXJ+nC84fNHCEMEkPZOw0Qyu7UFdsOX7DQaPHphWAVzPnGWkSy5CszeKfGMz d6YkHABZJSuT3zVDKk6lVRKBHyENp0Klk+BM3nNO79FLMOMJ0mVIdydbrRER4CZapVcj 5jwQ== X-Gm-Message-State: AAQBX9ce0MBRq8ffXkQsVaw3Bb68wgyS4h3aWQX/srQNfW+o7OTZuRwT HaD2pU1JrgbfKpruAPU2+fWU0Q== X-Google-Smtp-Source: AKy350YVQXm6lYtZvULpyqpbSjeEtFuN9Oe5oc/Cz5oizG0WdYVlrPUiEISFlV+6jXip/kd0cpTfbg== X-Received: by 2002:a5d:8347:0:b0:75c:3b4a:d13f with SMTP id q7-20020a5d8347000000b0075c3b4ad13fmr9482997ior.14.1681339962936; Wed, 12 Apr 2023 15:52:42 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id m12-20020a056638224c00b00403089c2a1dsm49002jas.108.2023.04.12.15.52.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Apr 2023 15:52:42 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id D7F6C8001C4; Wed, 12 Apr 2023 17:52:40 -0500 (CDT) Date: Wed, 12 Apr 2023 17:52:40 -0500 From: Justin Pryzby To: Michael Paquier Cc: Tomas Vondra , gkokolatos@pm.me, shiy.fnst@fujitsu.com, pgsql-hackers@lists.postgresql.org, Rachel Heaton Subject: Re: Add LZ4 compression in pg_dump Message-ID: References: <8ffd14fe-0278-7f8d-78d4-472816d06268@enterprisedb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Apr 13, 2023 at 07:23:48AM +0900, Michael Paquier wrote: > On Tue, Apr 11, 2023 at 08:19:59PM -0500, Justin Pryzby wrote: > > On Wed, Apr 12, 2023 at 10:07:08AM +0900, Michael Paquier wrote: > >> Yes, this comment gives no value as it stands. I would be tempted to > >> follow the suggestion to group the whole code block in a single ifdef, > >> including the check, and remove this comment. Like the attached > >> perhaps? > > > > +1 > > Let me try this one again, as the previous patch would cause a warning > under --without:-zlib as user_compression_defined would be unused. We > could do something like the attached instead. It means doing twice > parse_compress_specification() for the non-zlib path, still we are > already doing so for the zlib path. > > If there are other ideas, feel free. I don't think you need to call parse_compress_specification(NONE). As you wrote it, if zlib is unavailable, there's no parse(NONE) call, even for directory and custom formats. And there's no parse(NONE) call for plan format when zlib is available. The old way had preprocessor #if around both the "if" and "else" - is that what you meant ? If you don't insist on calling parse(NONE), the only change is to remove the empty #else, which was my original patch. "if no compression specification has been specified" is redundant with "by default", and causes "not the others" to dangle. If I were to rewrite the comment, it'd say: + * When gzip is available, custom and directory formats are compressed by + * default