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 1tfOFP-0024yd-RG for pgsql-general@arkaria.postgresql.org; Tue, 04 Feb 2025 19:06: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 1tfOFO-007PRY-RF for pgsql-general@arkaria.postgresql.org; Tue, 04 Feb 2025 19:06:10 +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 1tfOCs-007Jht-PA for pgsql-general@lists.postgresql.org; Tue, 04 Feb 2025 19:03:34 +0000 Received: from sm-r-006-dus.org-dns.com ([84.19.1.234]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tfOCq-003HpI-0O for pgsql-general@lists.postgresql.org; Tue, 04 Feb 2025 19:03:34 +0000 Received: from smarthost-dus.org-dns.com (localhost [127.0.0.1]) by smarthost-dus.org-dns.com (Postfix) with ESMTP id 3D824A0A1E for ; Tue, 4 Feb 2025 20:03:31 +0100 (CET) Received: by smarthost-dus.org-dns.com (Postfix, from userid 1001) id 31727A14F2; Tue, 4 Feb 2025 20:03:31 +0100 (CET) X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_INFOUSMEBIZ, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED, SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 Received: from ha01s018.org-dns.com (ha01s018.org-dns.com [62.108.32.138]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smarthost-dus.org-dns.com (Postfix) with ESMTPS id 9DC5AA0A1E for ; Tue, 4 Feb 2025 20:03:30 +0100 (CET) Authentication-Results: ha01s018.org-dns.com; spf=pass (sender IP is 146.185.68.202) smtp.mailfrom=thiemo@gelassene-pferde.biz smtp.helo=dummy.faircode.eu Received-SPF: pass (ha01s018.org-dns.com: connection is authenticated) Date: Tue, 4 Feb 2025 20:03:27 +0100 (GMT+01:00) From: Thiemo Kellner To: "pgsql-generallists.postgresql.org" Message-ID: In-Reply-To: <628D4022-5365-4D00-810B-10349A90874A@kleczek.org> References: <628D4022-5365-4D00-810B-10349A90874A@kleczek.org> Subject: Re: Lookup tables MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Correlation-ID: X-PPP-Message-ID: <173869581050.1884766.18296606378674076678@ha01s018.org-dns.com> X-PPP-Vhost: gelassene-pferde.biz X-POWERED-BY: wint.global - AV:CLEAN SPAM:OK List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 04.02.2025 18:31:09 Micha=C5=82 K=C5=82eczek : >> =EF=BB=BF Unless the lookup table is actually a check constraint one can= use to populate dropdown boxes in an interface. > > That is even worse because it ceases being transactional and users might = select something different than what they see on the screen. In how far is a real check constraint less transactional? And in how far is= it more advisable to have a real check constraint and fill your dropdown b= oxes from another source and having to keep that source on sync with the re= al check constraint?