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 1whSLZ-000EYx-0x for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jul 2026 13:29:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1whSLX-007Npw-2T for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jul 2026 13:29:52 +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 1whSLX-007Npo-1Y for pgsql-hackers@lists.postgresql.org; Wed, 08 Jul 2026 13:29:52 +0000 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1whSLV-00000000HEO-0nf7 for pgsql-hackers@postgresql.org; Wed, 08 Jul 2026 13:29:51 +0000 Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-493c59f740cso4897185e9.3 for ; Wed, 08 Jul 2026 06:29:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783517387; cv=none; d=google.com; s=arc-20260327; b=LD2XeeyckB0jZHB3aYoaaDJcPXGp6/Y5y/G/0CV47bUl+D4zt+tdQ6Kl7y4L93gqV3 hD6fclbx6UgOuaUQFLqgFTj/dfTFChWxunkTmt04aw7BwOoL9UFKBYQy4+9QIRZ3yu8u aMTSkuL+psCqgvInR9QrdK/BVzBoStzcUkBFSCjh922DhyV6P/wcpM1uedlqvYWjTIck zM52/GJjGx0Eql0Hd/YQ2GfwsqG8jvLX66j3z8TUPOGaKjWnnm44Zh60dN37k4z/1U2m g4RG2g5CgGvpGrXTOMiY9BpMboUVPim32RhN6w9bYM0MjcXt37Bq1lwS+3sJczGfGW3O gywg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=DrYTPYhqRyywR22mrmacIKHeYzXphlijxI7OZNNV0FU=; fh=qHlHCLRm8ZOXjRkSPBxuJSzyNz9D3k3KIMDp6nzFRkc=; b=g/ucywVOn/FK0PwsHGuDNHZq9TfBsxQS7kNNR1icS3NIuqhUberkyEYQ9+ptT0v4cf Fs3rcOHfBapzWdQZctEXjLZPfMxd4R32qRuwoghyJndaxeOm8imL+KAOKh0hD43VBCFc v67ei9oSoY4j87zZNmlFPLSHjGF9LZ6VK+o16+rrcsMzayRAxOL8t2Z4NE1rOol69dEA DodFqBQ7x9slcx/6WLgEquBiEBSNNCBeo6nkzIAHnUyksV7pp/qZX6W7Dxhqyuko9cyg PuQ8fsbZOvXYAskstv11clcvbTj0w1b1Bhv5o8Zu8EerSQsuINFxH5tzsvqV4B8tzF4o 0Bjw==; darn=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=20251104; t=1783517387; x=1784122187; darn=postgresql.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=DrYTPYhqRyywR22mrmacIKHeYzXphlijxI7OZNNV0FU=; b=PkPbeE1fnX/H4p1BxYaBCqYj2LP0VNr0WQJCVOfXDwARjCbnLI0ADKCHO7hzp34P0c 616w7fJzbITfpuWyaBB/DYyL9JQYlxLev0emiN2DMwvCN/2GQfuHq+6hQyVhY3guy4vQ gBEbnEBJRdIPEUyrBb9jvTpoTh/bhDzRJeM7AwI5+xzUiNzfJwaP6BrtTtKUD6Z4Cvdg jnH3YJhUUr4W7NX880yVvWg0wG8NHFDaCdh8XD5/UAxhUZ4bpQypR0UpsB45oGIyCnld 52Umvbdz8GIzwewdoO09TOLFTZ90SNCbwCYoV2JTzTabqHoon8lg99ErUXvOTefrS25Z 4bkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783517387; x=1784122187; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=DrYTPYhqRyywR22mrmacIKHeYzXphlijxI7OZNNV0FU=; b=p8X+PfJH8ULczxKACHOUA6loW3Sfk6XnfVTgr+DIJ4oV48MAK+7ElZPzkHN8HIn7FS ykkLiHoMCRyqVcnPTrL20XUUi2ZS/PUqaWJ30AIpUck/fxRffBzqFevFlF90r0z4GrBq WyrnzU29eScjmfecgoaJqR5ttgLbnHmJvWMFDz9xZdy5qG04IGhOQ7lrOO/HbR60f5qL fyyx++LX29qC8qJQfMyLVIZU7awmLBHBgf0TBjMwIS/s2IBCEuXRiGGNucLD9gQbvn/J eL8Gb0wiU9I3i5+NQ8SAHNgFrka99pvR1L/J2a/mGDm3aLRChSV3Ppj0DCnYkCG/F14z tIYQ== X-Forwarded-Encrypted: i=1; AHgh+RrQHusRCcRtvGwiyeO52mSsPb488qGLF3DpbQZFevHkopd+Dv/rQ0sXv45JH9fJFdV7VG6yIIF5aniewaQa@postgresql.org X-Gm-Message-State: AOJu0YzuaXoTmSU65tnwtZwCpoD/yXhiBad1GMfmq88vCNLFioSsO+YH DpHd4K5tick+5DkS7+oT8J/Dfxt7JPi5DbJQhYrL9bMXk1iem0IT/DkxE3bMVBYiGz+2tAB0vpA 1DYCuyo7RCF7JvwjDnFFPMAGwnHnEKgYSWG5K X-Gm-Gg: AfdE7ckILiOQ2AUsXIONL8CvTYTeFGHFydHC835O20B1aQkZPGS7kQAd/IOo6RUbBWB Wxz5kU9t/4vf91/puKPhwKM3J8jiMxOePjq6JYkP784SbN8fWDnHoXXkGb1PEFthWVvtu0YVueY 9z1wQ8SEi5rk0qw4xv1ztvm1mx2bkdkLmqZJksZKruZl18+YdR22KQ+KXcI81JRr/Y5GBSUqwmf QBqt574zsSBrIDu4iDFcZ8bTI73gcc1r3o0sNhqFQIKIGzF08tVA/YLtK//Rpo21Zhc5y7b1ESy WBdWGGWpW/3dAppEuOkqxljYmU/I+vTY6EvX2iXfIS2Gs5tBfdf19YVb/kOSZz2HhGSOYlbFwrO XbnVG0eBkOnuT3yUxFUhL01t6rImzzBWbI1gBQJXNWLhrS1VLyEmXPPWpwwxi3XqhFSTXA/PW X-Received: by 2002:a05:600c:6206:b0:493:d078:796 with SMTP id 5b1f17b1804b1-493e6a4a8a4mr24501635e9.17.1783517386967; Wed, 08 Jul 2026 06:29:46 -0700 (PDT) MIME-Version: 1.0 References: <20260630173053.51.noahmisch@microsoft.com> <517efb40-dcf8-4ff5-bfa6-c2bbf18ff64e@eisentraut.org> In-Reply-To: <517efb40-dcf8-4ff5-bfa6-c2bbf18ff64e@eisentraut.org> From: Ashutosh Bapat Date: Wed, 8 Jul 2026 18:59:33 +0530 X-Gm-Features: AVVi8Cf4rJUFwAp0deeBn1u26K06zOqJz8uYizVgVL4EvqWcK4PnC0XncOoGyVc Message-ID: Subject: Re: Wrong query result w/ propgraph single lateral col reference To: Peter Eisentraut Cc: Noah Misch , pgsql-hackers@postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jul 8, 2026 at 2:35=E2=80=AFPM Peter Eisentraut wrote: > > I would like this code to be organized differently. Note that the > existing insert_*_record functions don't do any error checking; they are > just there to make catalog modifications. There are various check_* > functions that pretty much correspond to syntax rule checks, but these > are run after the catalog changes, hence the present issue. Maybe we > should have a set of "pre-check" functions in addition? > I chose to perform the checks in insert_*_record() functions to keep them at a central place instead of dispersing all over like the check_* functions. The latter need to peform their checks considering the overall shape of the property graph, however, the specification checks are fairly local - like duplicate property or label names specified in the same command or duplicate labels being inserted - they won't usually need checks across labels or elements for example. I am afraid we might have to sprinkle pre_check_* functions at multiple places - thus leading to a risk of missing places as this code evolves. Do you expect insert_element_record() to perform sanity checks of labels or insert_label_record() to perform sanity checks on properties? Or do you expect a hierarchy of pre_check_ functions cascading from elements to labels to properties? --=20 Best Wishes, Ashutosh Bapat