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 1tuoc0-00C7Fi-BY for pgsql-general@arkaria.postgresql.org; Wed, 19 Mar 2025 08:17:17 +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 1tuoby-00GdiW-PP for pgsql-general@arkaria.postgresql.org; Wed, 19 Mar 2025 08:17:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tuoby-00Gdfv-4R for pgsql-general@lists.postgresql.org; Wed, 19 Mar 2025 08:17:14 +0000 Received: from 9.mo581.mail-out.ovh.net ([46.105.60.248]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tuobu-003izk-0I for pgsql-general@lists.postgresql.org; Wed, 19 Mar 2025 08:17:13 +0000 Received: from director8.ghost.mail-out.ovh.net (unknown [10.108.2.115]) by mo581.mail-out.ovh.net (Postfix) with ESMTP id 4ZHhQF6S0Cz1JFb for ; Wed, 19 Mar 2025 08:17:09 +0000 (UTC) Received: from ghost-submission-5b5ff79f4f-4ftxz (unknown [10.110.188.95]) by director8.ghost.mail-out.ovh.net (Postfix) with ESMTPS id 5A5581FDFB for ; Wed, 19 Mar 2025 08:17:07 +0000 (UTC) Received: from ilm-informatique.fr ([37.59.142.105]) by ghost-submission-5b5ff79f4f-4ftxz with ESMTPSA id cPNGFYN92mcvUgAA0bux0Q (envelope-from ) for ; Wed, 19 Mar 2025 08:17:07 +0000 Authentication-Results:garm.ovh; auth=pass (GARM-105G00657d6c0b0-8a30-4b93-ba8c-a6c9858acea8, 2ED49013BC27A568DD41F9660C18C78551FA769F) smtp.auth=sylvain@ilm-informatique.fr X-OVh-ClientIp:77.153.240.138 Message-ID: Date: Wed, 19 Mar 2025 09:17:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Restoring only a subset of schemas To: pgsql-general@lists.postgresql.org References: <7d869dac-5fe0-488c-a7a1-436b1d939057@ilm-informatique.fr> Content-Language: en-US From: Sylvain Cuaz In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 9044635429106803417 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddugeegkeefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpefuhihlvhgrihhnucevuhgriicuoehshihlvhgrihhnsehilhhmqdhinhhfohhrmhgrthhiqhhuvgdrfhhrqeenucggtffrrghtthgvrhhnpeeftdeftdehueehffevffekfeejfeffudduleelhfelvddthfdvueehtedugfefueenucfkphepuddvjedrtddrtddruddpjeejrdduheefrddvgedtrddufeekpdefjedrheelrddugedvrddutdehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpehshihlvhgrihhnsehilhhmqdhinhhfohhrmhgrthhiqhhuvgdrfhhrpdhnsggprhgtphhtthhopedupdhrtghpthhtohepphhgshhqlhdqghgvnhgvrhgrlheslhhishhtshdrphhoshhtghhrvghsqhhlrdhorhhgpdfovfetjfhoshhtpehmohehkedumgdpmhhouggvpehsmhhtphhouhht DKIM-Signature: a=rsa-sha256; bh=OTKw9RwJ5YAdW7Vlk3wsU2ph6erhTw3lPkH/8NKUvmg=; c=relaxed/relaxed; d=ilm-informatique.fr; h=From; s=ovhmo24547-selector1; t=1742372230; v=1; b=j71wQhKNS0+QI4+ib9Nz9OQuiF/5UFB8hQ+Hcw39EwdWOtq0p1Y6b9XV/wVdCEIMnd1yedXC 3cZQza7/IGPm+oDwJogu3DTdgFaYJC8D7sqf7h0hFNJfc5t6aLV3xeMUrmUGty6kHa+QqT0NR1V mzvepdmv6A2u131Of1ZDGn9SlAvfmFL8cllNVQN3w3q0XKxfk3qjNzItaSeTeYqMeM0zjeAlhPX 7+Y2r5lEKSkhVDLcAX75AulkZLWUem/iopy1Gzp/85pB6ZIsIelAkydA6YMiUq2anb7iZfbaCPu DcANw84lDk7Hbg8iZuVp/55vL/Vvo5L8hnzY566b/mXeA== List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Le 17/03/2025 à 16:21, Adrian Klaver a écrit : > On 3/17/25 07:57, Sylvain Cuaz wrote: >> Hi all, >> >>      I have a DB with one schema named "Common" holding data referenced by other schemas. All >> other schemas have the same structure (tables and fields) and are named "cXXX" where XXX is just >> an int. Thus the only cross-schema foreign keys are in "cXXX" pointing to "Common", and each >> "cXXX" is completely independent of other "cXXX" schemas. >>      Now if I want to restore from a full dump of this DB, but with only one "cXXX" and the >> "Common" schema : >> - if I pass --create --schema=Common, then the CREATE SCHEMA is missing, i.e. it only emits data >> inside "Common" and the restore fails. > > I am not seeing that. > > For: > > pg_dump -d test -U postgres -s --create --schema=other_sch --schema=public > > What is the complete command you are using for the pg_dump? Hi,     As I said I'm restoring, not dumping. I make daily full backups and sometimes need to restore a specific day, but the full database is quite big and I would like to only restore one or two schemas. As you said, if one passes --create --schema to pg_dump then a valid SQL is produced with CREATE DATABASE, CREATE SCHEMA, CREATE TABLE and all objects inside the schema. But if one passes --create --schema to pg_restore then an invalid SQL is produced because it contains CREATE DATABASE, CREATE TABLE but it doesn't contain the CREATE SCHEMA needed for the tables. Is there any reason for that discrepancy between dump & restore and for outputting invalid SQL ? My proposed --include-create-schema would just add the CREATE SCHEMA so that pg_restore behaves the same as pg_dump, and would allow to output valid SQL. But ideally this option shouldn't even be needed because pg_restore would just emit CREATE SCHEMA like pg_dump. > > What Postgres version(s) are you using? A lot :-) But for this problem I'm using 13 & 15. Cheers, Sylvain.