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.96) (envelope-from ) id 1vw6V3-002wDF-28 for pgsql-general@arkaria.postgresql.org; Fri, 27 Feb 2026 22:39:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vw6V2-007Msq-10 for pgsql-general@arkaria.postgresql.org; Fri, 27 Feb 2026 22:39:56 +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.96) (envelope-from ) id 1vw6V1-007Msd-36 for pgsql-general@lists.postgresql.org; Fri, 27 Feb 2026 22:39:55 +0000 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vw6Uy-00000001di4-33lX for pgsql-general@lists.postgresql.org; Fri, 27 Feb 2026 22:39:55 +0000 Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-65f90233e28so4895330a12.1 for ; Fri, 27 Feb 2026 14:39:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772231990; cv=none; d=google.com; s=arc-20240605; b=PEUyr5FsQ/B1Id7juzanWr5dfIQHzpvxwoIRX8BogUiMxVdzvpBzJYkrX6PCxBbP2X 0xqABRgE/2kG7GYk95zxK9oOYZ43C4dIERQfLhC8pL6lxJoa+OzMWDY2ekUYvc76V8RA YgCpdihqova2G318COtGNnXKzjn5F20z1eeUe//ZEtppuYFyXQJ4zTKkNKPYz/F93bLi M3943Kaix5GsNWfdTsd/kR6/2MU2bUWBkYg7/yRwxRt5JV6N/hG8/pudsCXNlDOhr7Lp XWSOfeDPWx/A58vGNYjLLs21xLOpNO8I86gS/v3I9BCvzAa6hK2gSOetfUmJ/p8pzKux HgYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=hGcCNJL40y1grbkAeFBVcAkLx5HTcMascr+Nz7ipzr4=; fh=4rCG0PM8n0FOokGy8sSWDJpgPdCgp6yIXcpABJ7tUh0=; b=e2995c908S9XCMY73DcTR/gHOnb2D9FH50lKzblVcypV8vQqYy6iRBZBVfo5iC02BX MQOrWweKVvb3bXF+1rS4iFvbXi2ghgdDw3P0zyjmZ1vq38rYrjSI/rlDAwQeDtIvSNd0 ehI2pV469fYJwdb1BFpQi1agThOwEOL3Mc0d+2i8giUn77mpDX3l5VPCkFB1XbAItEyu H9MOZxtlKoHrjSm+yj2HJVLA9MQGk2bGsWS3zQXuJrdcyID3EzaBL5fy0VHOJfzvcmx7 w48wffoQHL/cxsLqGAmwlOkKMF52qL+Ih6hI6kqXiS2yEgijpvXTGPJBv4MIOf/jCGQv GW9w==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772231990; x=1772836790; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=hGcCNJL40y1grbkAeFBVcAkLx5HTcMascr+Nz7ipzr4=; b=RCdOqfmQ/zjwisZUj4+T+qXniTh84mTKDoKn5rPCruLHSMEIqEHYaGa+svMtMrJ1be 1cQ8ljhma1KUD3Gd3XWFPCmI9+xFp2GXhsei9s/IqSAYz5QHlOQsf13aRKvFo/6zFc0h 40ajXBvRJvyMtUwxFf7/SKPxL9MFUxBL8OcXxHeY4aMhQZZzZ9Bi+kwG2JJPye1EyNE3 6/beDv8Dki7aIASEhdfKVv59x0tgIzlGixn2w4YGglj33Uf4sGasRNwWxs3JrdjQ4TZI rvBJ3hWfnQsWO4vFYQ01XKwp0ZPFJ6kGDlCI0m25M6OuQ9T/GPHZQlBluoAS4bym45GR tQzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772231990; x=1772836790; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hGcCNJL40y1grbkAeFBVcAkLx5HTcMascr+Nz7ipzr4=; b=R1FhGeUGkc70RVwxthCBFikkKldICn4OgxEYeQOVYgHTOc+SsS1zq/cb6wVrbsvMZ5 Iob4sSUtu3qKqQp1RuwnEO/AuNSVbAkYYcpw39odXGaPkYRfwSUjyAbpMFVOrC2CC/ZH 1IAuzMnffr0TtvBTG7vkaiDr8OVGhbLMQlRBbhzXP1Ldpf2BG30TxUSNrWHqTkvBy4Tl svNWcr9ifEo8YcBJ51AJk3H4nERin+GOkkv0PFgECwerffDWnVgHk18qNR7dxZJjSobW QPnXXgsBkhl0y2PipMm0MoUYv7RD4c7ZJMQc4xqEpjRny/v55mDkjOlK0qcSYp5IIfc8 76Sw== X-Gm-Message-State: AOJu0YyoNAONwI5up0gL6I7rrWGSgVrU8bD34XT66GoLAs31hXVFikzR OyFXWFOaAKKnjkg1pk0mo+nl6BoGGE9jg62yQBsHMfJnp2tzKwLzK2v/vnxqWT1hbm424nGRYWN kvAor9QC/mhqfCmNBqYaHAaE8Ruycvyh7veh4 X-Gm-Gg: ATEYQzzb2g33TGKVPGT2cpHghn/LPA1NeKQHbANq+4vljmtzoM8r/0mK0t7vKkU9UUh rKAZbrs3UnVvmnceuh4T1zNbsxtJFt4jxf7dN4V4jJ4UMZHgJv2gPbg2U/gY18gN5LqBCrSVDCP omxWpNITqJEk98lPyNv4TgQ2fVv7Rf2JDwBwhJYX2yk1zIeakDwSSn1zeC8vNG5YGAHAjDsKooq KM9KXFgWIqSNHAAyrhkyFkLPTgh+EqAcAUpzxTCA1SeeCjFnz/0Zx6utcKivhYZN3wBZ1kS/gUH GTG7vhggXzKzoj9PKkY= X-Received: by 2002:a05:6402:26c6:b0:658:3972:3a3d with SMTP id 4fb4d7f45d1cf-65fdddef2fbmr3258341a12.15.1772231990268; Fri, 27 Feb 2026 14:39:50 -0800 (PST) MIME-Version: 1.0 From: dfgpostgres Date: Fri, 27 Feb 2026 17:39:39 -0500 X-Gm-Features: AaiRm503ori6RZeCOjZJRzLq-B6eiqPWuDhJpXEJVBDPfTPl0DYl2KJYnQsnUZM Message-ID: Subject: Can "on delete cascade" dependency be used in pgdump or similar ? To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000003d57e6064bd5ea49" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003d57e6064bd5ea49 Content-Type: text/plain; charset="UTF-8" pg 15.15 on linux I have a DB with a table called "projects" which has a primary key column called "project". Other child tables are linked in a primary/foreign key relationship to "projects" with "on delete cascade". Each of those may have grandchild tables linked in via other primary/foreign key relationships, all with the "on delete cascade". Etc... . If I delete project "a", it'll cascade delete the children, grandchild, etc... recs. All traces of project "a" will be gone. But I don't really want to lose the data from project "a", I want to archive it in another DB (same DB server, different DB). The brain-numb method I've been using thus far is to copy the whole DB via pgdump then use that to create the DB "a_archive". Then (here's the wasteful part) basically delete all the projects in "a-archive" EXCEPT for project "a". Then, when that's done, go to the main DB and delete project "a". In effect, I just archived all the data for project "a" and put it in the DB called "a_archive".while relieving the main DB of the project "a" data. But what would be really neat is to leverage that cascade on delete stuff to just pgdump project "a" and use that to create "a_archive". Can pgdump do something like that ? Is there a better way to approach this problem of archiving one project (remembering that we do have the "on delete cascade" set up) ? Thanks in Advance ! --0000000000003d57e6064bd5ea49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
pg=C2=A015.15 on linux

I have a DB with= a=C2=A0table called "projects" which has a primary key column ca= lled "project".=C2=A0 Other child tables are linked=C2=A0in a pri= mary/foreign key relationship to "projects" with "on delete = cascade".=C2=A0 Each of those may have grandchild tables linked in via= other primary/foreign key relationships, all with the "on delete casc= ade".=C2=A0 Etc... .=C2=A0 If I delete project "a", it'l= l cascade delete the children,=C2=A0 grandchild, etc...=C2=A0 recs.=C2=A0 A= ll traces of project "a" will be gone.

B= ut I don't really want to lose the data from project "a", I w= ant to archive it in another DB (same DB server, different DB).=C2=A0 The b= rain-numb method I've been using thus far is to copy the whole DB via p= gdump=C2=A0then use that to create the DB "a_archive".=C2=A0 Then= (here's the wasteful part) basically delete all the projects in "= a-archive" EXCEPT for project "a".=C2=A0 Then, when that'= ;s done, go to the main DB and delete project "a". In effect, I j= ust archived all the data for project "a" and put it in the DB ca= lled "a_archive".while relieving the main DB of the project "= ;a" data. But what would be really neat is to leverage that cascade on= delete stuff to just pgdump=C2=A0project "a" and use that to cre= ate "a_archive".=C2=A0=C2=A0

Can pgdump= =C2=A0do something like that ?
Is there a better way to approach = this problem of archiving one project (remembering that we do have the &quo= t;on delete cascade" set up) ?

Thanks in Adva= nce !

=C2=A0
--0000000000003d57e6064bd5ea49--