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 1kcrsZ-0002P2-V3 for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Nov 2020 15:17:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kcrsY-0003eX-RV for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Nov 2020 15:17:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kcrsY-0003eQ-KU for pgsql-hackers@lists.postgresql.org; Wed, 11 Nov 2020 15:17:46 +0000 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kcrsW-0003pA-1k for pgsql-hackers@postgresql.org; Wed, 11 Nov 2020 15:17:46 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id A8D641928; Wed, 11 Nov 2020 10:17:39 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 11 Nov 2020 10:17:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=VoyCYDVU+95yQ2IJz mbTd9gTbli5epDl5N08H68tKDI=; b=WF5rx0e0FHnftgJfF7SwcOjw/habcOh45 FfSJY0gHPJRwRlBJyKc9dH8RPPO07OMKWeYkmOSm34I2U9/7uIbvSImZoYqRf4m0 un9aJDxkRLuMBAaedWqVmtaYAaRvkDRxz7vWOI37zOTGGMrmbbA/VOqd/H7MMwQY OxpUyuV2il1M/zipYzJI4trEtYW/m/v9Z+1qgGLvqmZHYLrfUkuDz/aBB6Vd36DX gXbK51bxtsmx7ZTsa/jAvIf1URXk2RXm+YzS0l2liTG+ZcOo9OaOJpNnbEObgftS /0QzlsFZgVb6AYPD+lXtCN6ykqFFT/Lyx4dp2kL/B/8LkTchpPNrA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddvtddgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggujggfsehttdertddtredvnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeevgfelveegueejgefhgeetgefhgeehieefheehleetteei udeiiefhgffgheffteenucfkphepudeltddrleehrddukedrjeelnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhv hhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.18.79]) by mail.messagingengine.com (Postfix) with ESMTPA id 7142E3280067; Wed, 11 Nov 2020 10:17:38 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 3476F2A14F6; Wed, 11 Nov 2020 12:17:36 -0300 (-03) Date: Wed, 11 Nov 2020 12:17:36 -0300 From: Alvaro Herrera To: Pavel Stehule Cc: Stephen Frost , Surafel Temesgen , Tom Lane , vignesh C , Justin Pryzby , PostgreSQL Hackers , Daniel Gustafsson Subject: Re: proposal: possibility to read dumped table's name from file Message-ID: <20201111151736.GA24124@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Nov-11, Pavel Stehule wrote: > I think the proposed feature is very far to be the config file for pg_dump > (it implements a option "--filter"). This is not the target. It is not > designed for this. This is just an alternative for options like -t, -T, ... > and I am sure so nobody will generate this file manually. Main target of > this patch is eliminating problems with the max length of the command line. > So it is really not designed to be the config file for pg_dump. I agree that a replacement for existing command line arguments is a good goal, but at the same time it's good to keep in mind the request that more object types are supported as dumpable. While it's not necessary that this infrastructure supports all object types in the first cut, it'd be good to have it support that. I would propose that instead of a single letter 't' etc we support keywords, maybe similar to those returned by getObjectTypeDescription() (with additions -- for example for "table data"). Then we can extend for other object types later without struggling to find good letters for each. Of course we could allow abbrevations for common cases, such that "t" means "table". For example: it'll be useful to support selective dumping of functions, materialized views, foreign objects, etc.