Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qwVhW-00CFNr-1N for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Oct 2023 22:53:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qwVhT-001wQk-5D for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Oct 2023 22:53:07 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qwVhS-001wQc-Rt for pgsql-hackers@lists.postgresql.org; Fri, 27 Oct 2023 22:53:06 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qwVhQ-002dma-4m for pgsql-hackers@postgresql.org; Fri, 27 Oct 2023 22:53:05 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 39RMr01V1618734; Fri, 27 Oct 2023 18:53:00 -0400 From: Tom Lane To: Bruce Momjian cc: jcarson@fastmail.com, PostgreSQL-development Subject: Re: request clarification on pg_restore documentation In-reply-to: References: <166446181317.661.16517798061228916974@wrigleys.postgresql.org> Comments: In-reply-to Bruce Momjian message dated "Fri, 27 Oct 2023 18:33:38 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1618732.1698447180.1@sss.pgh.pa.us> Date: Fri, 27 Oct 2023 18:53:00 -0400 Message-ID: <1618733.1698447180@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Bruce Momjian writes: > Does anyone have a suggestion on how to handle this issue? It might be that the later decision to change the representation of sequence dumps would make it possible to undo 4317e0246c and go back to having --schema-only/--data-only be true aliases for --section. But it'd take some research and probably end up causing some behavioral changes (eg. trigger handling as you note). Much the same research would be needed if you just wanted to document the current state of affairs more clearly. The real issue here is that --schema-only/--data-only do a few things that are not within --section's remit, such as trigger adjustments. Do we want to cause --section to have those effects too? I dunno. Do we want to give up those extra behaviors? Almost certainly not. Either way, I'm not personally planning to put effort into that anytime soon. regards, tom lane