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 1tacRr-003Xcp-G1 for pgsql-general@arkaria.postgresql.org; Wed, 22 Jan 2025 15:15:19 +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 1tacRq-000o5K-IO for pgsql-general@arkaria.postgresql.org; Wed, 22 Jan 2025 15:15:18 +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 1tacRq-000o5C-7U for pgsql-general@lists.postgresql.org; Wed, 22 Jan 2025 15:15:18 +0000 Received: from mail-oa1-x2b.google.com ([2001:4860:4864:20::2b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tacRo-000vYa-0J for pgsql-general@lists.postgresql.org; Wed, 22 Jan 2025 15:15:17 +0000 Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-2b1a9cbfc8dso1754628fac.2 for ; Wed, 22 Jan 2025 07:15:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737558916; x=1738163716; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=k8aULFdHmbj2SlJUXaNQ5EwkDm8Vd+mo/PG4mnTcK5E=; b=ikfsmMU4NEHgSCWcm5Y/DtFZ/1ZMSrcGAFX2dUOtKuYVyfuy9OqvO0IHvwmc8FZBiS SW/2VJWdOZsKYHOaaI9Z4gD1A3X31amu5t+23s2EFkBDF+kOcdePDlC6zpEWZUPcz+Bq DdqG7bm+/75Rchi0CURg2iz0/ybPAdDJTY4GCvsKFWwUlzINGWMubCj2lhjaWHcyI/YI 2VAEjvFUHqamn+Y4n/DrdGZvEn9EEUZHrfe4lex59XKSMFyrQ8Nsn4ShOP982F8hldqP 5GAaKNXgbVGeFZeE3Ds2ROTnEa4tlaCHn4jOudtqt/JUzqjgZhNMB0R9Ls8ftamdg0AX fgnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737558916; x=1738163716; h=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=k8aULFdHmbj2SlJUXaNQ5EwkDm8Vd+mo/PG4mnTcK5E=; b=ut7NBbS3p2sqKrFyCdszHWuL0jOD1ilYq5pzfmUbHzkAEtsd/3N9aHW2n60f1U3M0I geKMVUz/5GCfieQ+V92ZnSUq1y35yzdXbZhZIxZEWHPyPzroK4sdrkhVBJl2AddFvMga aCylDL9INLzbHH6H8Z6TAEUjJ86K5pUxE6WE1Cw2dBMilhxi9px7eHVoAJAGmEQxbDpl CAsuSeCqx6aSx2un118FeKIRvMdPjvWioruWxXL2JrU8pqYqbd71QefkXI5wQB4SYV2y mkP2OvhsoPmJGzYJrZaTXw6UU2rS31VgV3XaFDhPiQ/1Ha1KKZk1JCo9/jE3AiX8EoZ5 VNzw== X-Gm-Message-State: AOJu0YyREGtmzpydceycR6kR5qTd1NOqueZvqQ3yaU5TwM9jzgNI4B6N 3whUY9GIXCA3iXGsaARhwp+njVYfTHbsukMt5jWBxZGcpg64eGj5W36CF1J/VbIxrohjL1dJPOZ RMrQLaIzIctRhCOZPp6OtrIPqU/GSWA== X-Gm-Gg: ASbGncsPZEwamk5zYSbkVD3PeHKmNvOzsnddqXh6nbF53mTEbfNk8HMgS7I+SFWuI4u R9+1SRpyRbrtTuf6c5WijKh+vB5BAUdm1uW45OxERvoxFoCgl3SAK62d0PCqYIOU= X-Google-Smtp-Source: AGHT+IH/kQ/wLN9LZug2FWam/gJmwsYwFwjDbWNsK2gGfRUZxD/enSNzgOadGms4ZUjTnQ9LKHmOtVK/m+suHpIh7Lw= X-Received: by 2002:a05:6871:3803:b0:29f:ed90:8d11 with SMTP id 586e51a60fabf-2b1c0af332dmr15240479fac.29.1737558915572; Wed, 22 Jan 2025 07:15:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Wed, 22 Jan 2025 10:15:04 -0500 X-Gm-Features: AbW1kvb6b7E0i_SrP8478fsC4qqwAwXrPsRp6j9bNezif8l3RLgvV2GNQfbXCi0 Message-ID: Subject: Re: Automatic deletion of orphaned rows To: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000f06b7d062c4cf51b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f06b7d062c4cf51b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 22, 2025 at 9:37=E2=80=AFAM David G. Johnston < david.g.johnston@gmail.com> wrote: > On Wednesday, January 22, 2025, Ron Johnson > wrote: >> >> >>> I therefore propose a feature, to be able to specify in a table schema >>> that a row should be deleted if orphaned. >> >> >> For one thing, rows *can't* be orphaned if there's a foreign key >> reference. >> > > The description was correct even though using probably imprecise > terminology. The basic goal is to delete childless parents. > That's kinda what I thought he wrote, but it's so far beyond "normal" that I dismissed the possibility. Parents are allowed to not have children, after all. Is there *ANY* DBMS with a built-in reverse FK "parents must have children" feature? --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000f06b7d062c4cf51b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 22, 2025 at 9:37=E2=80=AFAM D= avid G. Johnston <david.g.= johnston@gmail.com> wrote:
On Wednesday= , January 22, 2025, Ron Johnson <ronljohnsonjr@gmail.com> wrote:

I therefore propose a feature, to be able to specify in a table schema
that a row should be deleted if orphaned.

F= or one thing, rows can't=C2=A0be orphaned if there's a forei= gn key reference.=C2=A0

T= he description was correct even though using probably imprecise terminology= .=C2=A0 The basic goal is to delete childless parents.

That's=C2=A0kinda what I=C2=A0thought he=C2=A0wrote,= =C2=A0but it's so far beyond "normal" that I dismissed=C2=A0t= he=C2=A0possibility.=C2=A0 Parents are allowed to not have children,=C2=A0a= fter all.

Is there ANY=C2=A0DBMS with a bui= lt-in reverse FK "parents must have children" feature?

--
Death to <Redacted= >, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
--000000000000f06b7d062c4cf51b--