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 1orQQa-0005r6-Vr for pgsql-hackers@arkaria.postgresql.org; Sat, 05 Nov 2022 21:10:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1orQPb-0005pX-LM for pgsql-hackers@arkaria.postgresql.org; Sat, 05 Nov 2022 21:09:07 +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 1orQPb-0005pN-AJ for pgsql-hackers@lists.postgresql.org; Sat, 05 Nov 2022 21:09:07 +0000 Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1orQPV-0007Yn-SJ for pgsql-hackers@postgresql.org; Sat, 05 Nov 2022 21:09:06 +0000 Received: by mail-pg1-x534.google.com with SMTP id r18so7198874pgr.12 for ; Sat, 05 Nov 2022 14:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=cqT8LHfAIGG6baqbmgTR2Cs3ZbxdL5wRdBXnROV2p/c=; b=j9WW9fN7DnuHWUVo0j+8zw7ZH60UQZuHJ9LXZCCkXgcfLubcz+HkUcwKbFxytazZF4 sHUw96ASByr12ZtOj993KXMfb6Wp+HucgwwxGWw0b8JyMfLchpEr4VyhnCiDAb2TdItU pNc4jatg+ufgLCTFRFirGZrQblP/SC5Gy6T/VtZiBIJBJprxCfsMuJIAN3nHtNieLLWO oFxlpiiEER5hNgkvwGrhzSsWGbLz2CxC9AlCrgoICVzehcDiuXGGI45cTDlDnAfsE5jX 55YSoqFNEOt7Kgxp1G19Yj/yZEfszAZNC4Brcwqz2EDGTXqwDDVds6SMqBnNP4HFc0tz uaFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=cqT8LHfAIGG6baqbmgTR2Cs3ZbxdL5wRdBXnROV2p/c=; b=QZI5y7k7ZMaS9SZ00NDzWufTj3BtxOEm+gNQnlHqiTgTKzI/nY/MmAZYyqSekJfHaM /OEWtAGHp0Ad5Xj5vK3wiePimjT4ASZlpoLZf+WOHnSGIbOnVT0a9eBH2edRFc4layQ8 JnZEXDxa7+cy1yzgUSjcuPJnpPmgzhl+yA1Vg1N4R4yYvlusLJCy0nqOPlCwzMetCIYS qvWatncfzrrQ/u0H1DC6ieznVOLSP45YGyFvvUqFrp5rNDHBmOEr+X4CjDAlRny3XttU 10Bx7ujWqx6RcNzkBt7yuCSwTPr5rxP2FrYZJ7ewRtoTPN/UHm/zQDvTlp+U07VrJMm9 RR/Q== X-Gm-Message-State: ACrzQf2FuECWj7H11VgUJVmu8aMnkDyFbWoxY8zGr3brdVIK0XBv0Qge oYOK7a3VU7R7S+VNwWR/qng= X-Google-Smtp-Source: AMsMyM4j1qhdpQlUp37P7xLyoJSolpAu7Lf6ccww04cMARg1GqOyTdHXTWdKpwZ9EGGivGLR+gYmvA== X-Received: by 2002:a05:6a00:21d1:b0:56d:6df8:2f5a with SMTP id t17-20020a056a0021d100b0056d6df82f5amr34063060pfj.9.1667682540765; Sat, 05 Nov 2022 14:09:00 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id p1-20020a1709027ec100b00186b3528a06sm2085978plb.41.2022.11.05.14.08.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Nov 2022 14:09:00 -0700 (PDT) Date: Sat, 5 Nov 2022 14:08:58 -0700 From: Nathan Bossart To: Michael Paquier Cc: Kyotaro Horiguchi , bharath.rupireddyforpostgres@gmail.com, tgl@sss.pgh.pa.us, peter.eisentraut@enterprisedb.com, benoit.lobreau@gmail.com, alvherre@alvh.no-ip.org, robertmhaas@gmail.com, bossartn@amazon.com, david@pgmasters.net, masao.fujii@oss.nttdata.com, pgsql-hackers@postgresql.org, magnus@hagander.net, sfrost@snowman.net Subject: Re: archive modules Message-ID: <20221105210858.GB137360@nathanxps13> References: <20221014185130.GC1678424@nathanxps13> <20221014214256.GA1819154@nathanxps13> <20221017.134639.1811443236787336786.horikyota.ntt@gmail.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 Mon, Oct 17, 2022 at 02:49:51PM +0900, Michael Paquier wrote: > And, by the way, this patch would prevent the existence of archive > modules that need to be loaded but *want* an archive_command with > what they want to achieve. That does not strike me as a good idea if > we want to have a maximum of flexibility with this facility. Such a module could define a custom GUC that accepts a shell command. I don't think we should overload the meaning of archive_command based on the whims of whatever archive module is loaded. Besides the potential end-user confusion, your archive_command might be unexpectedly used incorrectly if you forget to set archive_library. Perhaps we could eventually move the archive_command functionality to a contrib module (i.e., "shell_archive") so that users must always set archive_library. But until then, I suspect it's better to treat modules and commands as two separate interfaces to ease migration from older major versions (even though archive_command is now essentially a built-in archive module). -- Nathan Bossart Amazon Web Services: https://aws.amazon.com