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 1tacPo-003XOT-Iu for pgsql-general@arkaria.postgresql.org; Wed, 22 Jan 2025 15:13:12 +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 1tacOn-000jpf-EN for pgsql-general@arkaria.postgresql.org; Wed, 22 Jan 2025 15:12:09 +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 1tacOn-000jpW-3v for pgsql-general@lists.postgresql.org; Wed, 22 Jan 2025 15:12:09 +0000 Received: from mail-il1-x132.google.com ([2607:f8b0:4864:20::132]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tacOj-000vMo-1q for pgsql-general@lists.postgresql.org; Wed, 22 Jan 2025 15:12:08 +0000 Received: by mail-il1-x132.google.com with SMTP id e9e14a558f8ab-3ce6b289e43so62545885ab.3 for ; Wed, 22 Jan 2025 07:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737558724; x=1738163524; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qdC57YA1IM5uikGNuLS2AQzeBKI7Tj1t/AK0HVpg1dg=; b=QsQiBTt+IjMvQ7g7qhqytkEMEvcZTTiW7ubbfkdcM3ernMjXQDWl8/pMRRfkmNKAuQ +uWWMY/1cU86aOTDne0HQdrA/CWK32aAzKDTkoClepAm4eouF4zy5wJ4jRgq8bIfVKlx Exn4/o0EfnOj+gsiIw/CHlbklrHTJSq728tQmVj+4oHcFn9EyUzRFEfMnQ1ztIvqom/d 8TYg4AGICWGFpDI95GMefgLNlI5jq7BZF9fp5NjcPlvnDIeAVXhXPiZJWRYrkCn2NYEa OPKsiVKiDmiXJ1L5nP8XpWEVyHaRhSV7aqEO96VgZWpqhQXnEJ1v8GoYanbWCsFRgpZK HZGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737558724; x=1738163524; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qdC57YA1IM5uikGNuLS2AQzeBKI7Tj1t/AK0HVpg1dg=; b=WUaXPU1GXZp1xXTqZyzGnl2qgmgsmaF4TNdhFqqIgI05L60fOEjlNb+eJBkcJXvmzF m5uKkOP5Hdv8rnsTgGAFqXfkFk52Jls9JsmpXXC+e8FLXm6lFHqg7Vrf/2DoUH0QRa3B vLmsGZR+T1ulPerx5Hx38mATLTCdiM5cZfthbMn/rLG3GOSxeRlbiJJfgK73JkMAhzRR cL8rPhG8qqdFrnT74kpOY99ulLRmib+rLWaL+lKl6txWqLbXVyl67/v9DAVR53MIY137 MuqnfcGZOLb6xhR5up5lRAB3ZRC4ZLPJdjQBtqn7jOpCS4ZfcNj8K6SEhVucnXxnAM3V CV2g== X-Gm-Message-State: AOJu0YxPU0vh1mzrPLT9nonJeO+3G7N7wEOk5T+3n8bioWZI20v84AS+ h6AFGWaIdNtlOV3+xVesnn40zl7HSl4DnGngX/cEZ4H3uh7o53nzQDPY/AnjguADudS0it10aZG LWnhLb5POSPRiQZb3qRyYER/RELcdy1ul X-Gm-Gg: ASbGnctxfJhFsLB40+Y4fBHdrvRrE1svP/omGNF4tMzLA7fJBFJ74VN5eMa5vU6Ld1X VGaMGlfTOUQAC4Psi0AQD1Dj15xJNf9vjbp5xQfEuL3IU8eQlCIo= X-Google-Smtp-Source: AGHT+IFSdb1TaP1xJ4fFzTK3y1CoIpWTjFEL1WRxyru/n8jMO77D/dskmqhDNn3Zfx/O9m0ynKzbAA7tbd0hu5N7uEw= X-Received: by 2002:a92:cda1:0:b0:3a7:955e:1cc5 with SMTP id e9e14a558f8ab-3cf743b9350mr198608635ab.1.1737558722149; Wed, 22 Jan 2025 07:12:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sabino Mullane Date: Wed, 22 Jan 2025 10:11:26 -0500 X-Gm-Features: AbW1kvYhkjxwTdk_xRdM5Ydk6YDvkk93b_xiS6QCm-IPlXuBku3XQzGjgisEgf0 Message-ID: Subject: Re: Automatic deletion of orphaned rows To: Runxi Yu Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000690aea062c4ceacc" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000690aea062c4ceacc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 22, 2025 at 2:00=E2=80=AFAM Runxi Yu wrote: > I therefore propose a feature, to be able to specify in a table schema > that a row should be deleted if orphaned. > I think you mean "childless" rows, as "orphaned" has a different meaning traditionally. When and how would this deletion take place? And why not just run the delete yourself? It would help to show us exactly the behavior you want. Here's some sample tables we can use: create table parent( id int primary key ); create table kid( refid int references parent(id) ); insert into parent values (1),(2),(3); insert into kid values (1); -- remove any rows non-referenced rows (aka childless) delete from parent where not exists (select 1 from kid where refid=3Dparent= .id ); select * from parent; id ---- 1 Cheers, Greg -- Crunchy Data - https://www.crunchydata.com Enterprise Postgres Software Products & Tech Support --000000000000690aea062c4ceacc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 22, 2025 at = 2:00=E2=80=AFAM Runxi Yu <me@runxiyu.org> wrote:
I therefore propose a feature, t= o be able to specify in a table schema that a row should be deleted if orph= aned.

I think you mean "childless&= quot; rows, as "orphaned" has a different meaning traditionally.<= /div>

When and how would this deletion take place? And w= hy not just run the delete yourself?
It would help to show us exactly th= e behavior you want. Here's some sample tables we
can use:

cr= eate table parent( id int primary key );

create table kid( refid int= references parent(id) );

insert into parent values (1),(2),(3);
=
insert into kid values (1);

-- remove any rows non-referenced ro= ws (aka childless)
delete from parent where not exists (select 1 from ki= d where refid=3Dparent.id);

select * from parent;
=C2=A0id
----
=C2=A0 1

--
Crunch= y Data -
https://www.crunchydata.co= m
Enterprise Postgres Software Products & Tech Support
=

--000000000000690aea062c4ceacc--