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 1tuBu0-004qyd-1S for pgsql-general@arkaria.postgresql.org; Mon, 17 Mar 2025 14:57: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 1tuBty-00E33q-2W for pgsql-general@arkaria.postgresql.org; Mon, 17 Mar 2025 14:57:14 +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 1tuBtx-00E32t-Fs for pgsql-general@lists.postgresql.org; Mon, 17 Mar 2025 14:57:13 +0000 Received: from 11.mo581.mail-out.ovh.net ([87.98.173.157]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tuBtt-003L2p-37 for pgsql-general@lists.postgresql.org; Mon, 17 Mar 2025 14:57:12 +0000 Received: from director2.ghost.mail-out.ovh.net (unknown [10.108.2.235]) by mo581.mail-out.ovh.net (Postfix) with ESMTP id 4ZGdNd4Zx3z1H9k for ; Mon, 17 Mar 2025 14:57:05 +0000 (UTC) Received: from ghost-submission-5b5ff79f4f-l9b4b (unknown [10.110.168.250]) by director2.ghost.mail-out.ovh.net (Postfix) with ESMTPS id BD4D41FE80 for ; Mon, 17 Mar 2025 14:57:05 +0000 (UTC) Received: from ilm-informatique.fr ([37.59.142.96]) by ghost-submission-5b5ff79f4f-l9b4b with ESMTPSA id 2LHaHUE42GdUOgAA3XBeRQ (envelope-from ) for ; Mon, 17 Mar 2025 14:57:05 +0000 Authentication-Results:garm.ovh; auth=pass (GARM-96R001efae3c83-6387-4579-a88c-69cdb076101a, 4A62CBFD390C7A3DC168E92248BECCEB5AE92DB9) smtp.auth=sylvain@ilm-informatique.fr X-OVh-ClientIp:77.153.240.138 Message-ID: <7d869dac-5fe0-488c-a7a1-436b1d939057@ilm-informatique.fr> Date: Mon, 17 Mar 2025 15:57:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: fr, en-US To: pgsql-general@lists.postgresql.org From: Sylvain Cuaz Subject: Restoring only a subset of schemas Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 4053521139964633817 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddufeelkeduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefkffggfgfvhffutgfgsehtkeertddtvdejnecuhfhrohhmpefuhihlvhgrihhnucevuhgriicuoehshihlvhgrihhnsehilhhmqdhinhhfohhrmhgrthhiqhhuvgdrfhhrqeenucggtffrrghtthgvrhhnpeekvdegledugfefieetueekleejudeufedvfefhhfeljeekuddvgfeileeifefgvdenucfkphepuddvjedrtddrtddruddpjeejrdduheefrddvgedtrddufeekpdefjedrheelrddugedvrdelieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepshihlhhvrghinhesihhlmhdqihhnfhhorhhmrghtihhquhgvrdhfrhdpnhgspghrtghpthhtohepuddprhgtphhtthhopehpghhsqhhlqdhgvghnvghrrghlsehlihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrghdpoffvtefjohhsthepmhhoheekudgmpdhmohguvgepshhmthhpohhuth DKIM-Signature: a=rsa-sha256; bh=BCGUVdzt+ic2BFA/Adg1t2EkPGGuHafcyf6635x7wBQ=; c=relaxed/relaxed; d=ilm-informatique.fr; h=From; s=ovhmo24547-selector1; t=1742223425; v=1; b=m25Zcm4HRenKQc09+C50zMBDpgdAor3bnjwIk40URNkiF25Rbx19SqW1CZgSsZe5oHoRRHiD kCAb+2Fkafi2wYw8g64Ht3qa02tQ58Qp8t01M0WptqC8ic8gLFcvo+MhO2ygOt++hiTIz3A5e24 ZIeC9B2MTKDHXNgTDJ7OzxDe6dNy18EruWGn8nOhT8rhVEio81oeVSTGLSg/YmqwOcLEXSjKs+A 9hqSY9J7owaEVrWIWhosg5F+ygmbjDJ1lEzIAypYG3aIg/fKma59jNPaEM1Ep4yADjFzmfy7aB3 mLBv6uFqQMD46qxv9eGQ2Iumtv087rCFqmRHdp7wZOX/Q== List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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. - if I could pass --create --exclude-schema='c*' (fictional notation as patterns are only recognized by pg_dump), then all schemas would be created, with no data inside except for "Common". Creating all schemas is a waste of time, but more importantly would make restoring other schemas more difficult (e.g. rows should be inserted before creating foreign keys). Note : to check the behaviour of pg_restore above, I pass -f- to check the SQL as it is far quicker than to actually restore a DB. Maybe a new --include-create-schema option should be added to emit CREATE SCHEMA in addition to objects inside it ? That way I could : 1. --create --include-create-schema --schema=Common and have a DB with all DB-level properties (DEFAULT PRIVILEGES, COMMENT, SET parameter, etc.) and one schema with all of its data and schema-level properties (DEFAULT PRIVILEGES, COMMENT, GRANT USAGE). 2. then at any point later without the --create, with as many schemas I need :  --include-create-schema --schema=cXXX. And if I need to reset a "cXXX" schema, just manually DROP SCHEMA and restore again. Similarly, maybe add --exclude-create-schema to additionally exclude CREATE SCHEMA for schemas targeted by --exclude-schema. IOW --schema and --exclude-schema both target objects inside schemas, these 2 new options would allow to also have control on the schemas themselves (and their properties like DEFAULT PRIVILEGES, COMMENT, etc.) Cheers, Sylvain