Re: Refactoring of compression options in pg_basebackup

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>, Georgios Kokolatos <gkokolatos(at)pm(dot)me>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>
Subject: Re: Refactoring of compression options in pg_basebackup
Date: 2022-01-26 20:24:25
Message-ID: CA+TgmoZCuVxfVia+n+aCfkkZA=bZexOUmnU4vq=Psfa4FTdL+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 25, 2022 at 8:15 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> Sure, but I don't think that it is a good idea to unify that yet, at
> least not until pg_dump is able to handle LZ4 as an option, as the
> main benefit that we'd gain here is to be able to change the code to a
> switch/case without defaults where we would detect code paths that
> require a refresh once adding support for a new option.

I think those places could just throw a "lz4 compression is not
supported" elog() and then you could just grep for everyplace where
that string appears. But I am not of a mind to fight about it. I was
just pointing out the duplication.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2022-01-26 20:39:16 Re: Support for NSS as a libpq TLS backend
Previous Message Robert Haas 2022-01-26 20:17:38 Re: autovacuum prioritization