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 1jirrm-0007wy-8i for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jun 2020 03:57:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jirrl-0003CO-4I for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jun 2020 03:57:29 +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 1jirrk-0003CG-Q1 for pgsql-hackers@lists.postgresql.org; Wed, 10 Jun 2020 03:57:28 +0000 Received: from mail-io1-xd2a.google.com ([2607:f8b0:4864:20::d2a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jirre-0004vO-2J for pgsql-hackers@postgresql.org; Wed, 10 Jun 2020 03:57:27 +0000 Received: by mail-io1-xd2a.google.com with SMTP id p20so610668iop.11 for ; Tue, 09 Jun 2020 20:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=UmUvAp6LeAKWXu3BdCgDeWWpCLpAqaKl74azEJ9gKvo=; b=O6+nOl9cS0LjfLGjScoM5WcZMPtMXjdiXktIc8MnSP2Uox6+pXQ1azcBY0kK1QXYB9 2jRuEK54wkfOJxvedi6LThCcvHdjQ+OJxCvZFYEhqUFKo/VAxb8HSD4Etzu70tk6zY1w CNrTegbDqA/qn+zDHuluKwUkikqDFrVNmBijxWmSamKJyGP+jDG9JF8HiaHUuxUDRD1g B9454EtCXzL5OfSiWdipDhIN6K99rhV+P5MtaP0m4s1CxEtjowKRCnu5wZwwd0CUdL6D UvAJ/BewrAQ6b0KMTgK0VO1roantt9bQ6X2nmCao7n4z/jFBwCfxZbdv3/eLc5mQWfLL r5RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=UmUvAp6LeAKWXu3BdCgDeWWpCLpAqaKl74azEJ9gKvo=; b=BEw7vUiuWXyZcwwAOsJtK1hVtOUiT0p/uvxxSJAY9wQAP9r9EGrdreY9hEcH6FDbDa CWwyuggKU5O0IfxUW9XMmtDIeSnecZutYq/Togf9534FYsQSlzsPOwCVMP4M5axJJjVk hFQxj/oF7DWFd4qYC+z7AbH5LChc4iRQgBn/NRgIRMPyYH8BYzb81mISn+6jokd5X5gc h7P1HGowm+3oy5vypsSwfV5HB3fagJsg0r5Jko8Q4019dcepvoMY1ux34rrypCx+ZTN2 EYGNpoVFKYABZRbrT7Ahc7inEOFmTsJlN2kjihrx8Qh8WHC/sQXATynu5EIrQigIdkUH e8pQ== X-Gm-Message-State: AOAM531y71yvopMsz6ZUEi0Y8wU0DOHWxPKcY29XXs5PM4IXII4JMb4X sd4fpgIOG1pRdmwKWW/bxW4TcQ== X-Google-Smtp-Source: ABdhPJzlgjhdBwJuMka0wrjATfrOyxc7zo3Yj9HANcJtyh9T1/f2qGsVDOragnLHXwGqNnLZtYZjSw== X-Received: by 2002:a02:cccd:: with SMTP id k13mr1363723jaq.53.1591761441070; Tue, 09 Jun 2020 20:57:21 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id t72sm3203805ilk.23.2020.06.09.20.57.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 20:57:20 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id A16FF8001A4; Tue, 9 Jun 2020 22:57:18 -0500 (CDT) Date: Tue, 9 Jun 2020 22:57:18 -0500 From: Justin Pryzby To: Pavel Stehule Cc: pgsql-hackers@postgresql.org Subject: Re: proposal: possibility to read dumped table's name from file Message-ID: <20200610035718.GB14879@telsasoft.com> References: <20200529182514.GL17850@telsasoft.com> <20200608212957.GB22473@telsasoft.com> <20200609223042.GF26811@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Jun 10, 2020 at 05:03:49AM +0200, Pavel Stehule wrote: > st 10. 6. 2020 v 0:30 odesílatel Justin Pryzby napsal: > > > On Tue, Jun 09, 2020 at 11:46:24AM +0200, Pavel Stehule wrote: > > > po 8. 6. 2020 v 23:30 odesílatel Justin Pryzby napsal: > > > > > I still wonder if a better syntax would use a unified --filter option, whose > > > > argument would allow including/excluding any type of object: > > > I tried to implement simple format "[+-][tndf] objectname" > > I had another idea about format - instead using +-, we can use case > sensitive options same to pg_dump command line (with extending Df - > because these options doesn't exists in short form) > > So format can looks like > > [tTnNDf] {objectname} > > What do you think about this? This format is simpler, and it can work. What > do you think about it? I prefer [-+][dtnf], which is similar to rsync --filter, and clear what it's doing. I wouldn't put much weight on what the short options are. I wonder if some people would want to be able to use *long* or short options: -table foo +schema baz Or maybe: exclude-table=foo schema=bar Some tools use "long options without leading dashes" as their configuration file format. Examples: openvpn, mysql. So that could be a good option. OTOH, there's only a few "keys", so I'm not sure how many people would want to repeat them, if there's enough to bother putting them in the file rather than the cmdline. -- Justin