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 1tmrXV-00C2Nu-EM for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Feb 2025 09:47:46 +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 1tmrXU-00GwUR-8f for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Feb 2025 09:47:44 +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 1tmrXT-00GwUI-Oo for pgsql-hackers@lists.postgresql.org; Tue, 25 Feb 2025 09:47:43 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tmrXQ-000hys-2J for pgsql-hackers@postgresql.org; Tue, 25 Feb 2025 09:47:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1740476859; bh=AmZzMjOBLOi8JSdn4s4VqFQ44EvuPHezvCvhX3JaAJM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:Message-ID:From; b=GQdLB5gD/QMbL0Z2V7zIy7F9BGbm+tA0cWh2GHIDYLuHYziVR44TCBlYEzCEEMn2R aByPAffGQI5A1etGH8r1d+O/md89BH3KoZ+ya/gk4Y56Fr/VDQwYpV8kbcx6FLP9Ro w7qz7hPqG4smlaQXGx8zJxwsobpnEVCIaX8vgRLIJtOoKom/znSDEoNJEtaRWn82H8 Bjp2LSkxmNpTq2Pz3tmmnP4psq/lFtj4BdRzwzb4dKhyUMMRtv0O1O1KlYOyJ26Jem UQNbsykVqjlBtfPMh/P9kw++7Nob4qT0L1tryA0cNC6JvJljsIKSjGCjPesBBa4uYa 5RjJKeqBFwUPw== Received: from mail.postgrespro.ru (webmail-slave-mstn.l.postgrespro.ru [192.168.2.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: v.popolitov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id C17C360318; Tue, 25 Feb 2025 12:47:39 +0300 (MSK) MIME-Version: 1.0 Date: Tue, 25 Feb 2025 16:47:39 +0700 From: Vladlen Popolitov To: Junwang Zhao Cc: Ashutosh Bapat , Vik Fearing , Ajay Pal , Imran Zaheer , Peter Eisentraut , pgsql-hackers Subject: Re: SQL Property Graph Queries (SQL/PGQ) In-Reply-To: References: <04c0abe2-e9c5-4ffc-97b2-bedc1e3cd178@eisentraut.org> <3b190de8-910a-4091-82f9-e98cf562d832@postgresfriends.org> Message-ID: X-Sender: v.popolitov@postgrespro.ru Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-KSMG-AntiPhishing: NotDetected X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.1.0.7854, bases: 2025/02/25 08:32:00 #27449984 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi! I would ask about CREATE GRAPH PROPERTY. From my point of view it makes very strong check of types including check of typmod. Example: CREATE TABLE userslist ( user_id INT primary key, name VARCHAR(40) ); CREATE TABLE groupslist ( group_id INT primary key, name VARCHAR(30) ); CREATE TABLE memberslist ( member_id INT primary key, user_id INT, group_id INT, CONSTRAINT members_users_fk1 FOREIGN KEY (user_id) REFERENCES userslist (user_id), CONSTRAINT members_groups_fk1 FOREIGN KEY (group_id) REFERENCES groupslist (group_id) ); CREATE PROPERTY GRAPH members_pg VERTEX TABLES ( userslist KEY (user_id) LABEL luser PROPERTIES ALL COLUMNS, groupslist KEY (group_id) LABEL lgroup PROPERTIES ALL COLUMNS   ) edge TABLES ( memberslist KEY (member_id) SOURCE KEY (user_id) REFERENCES userslist (user_id) DESTINATION KEY (group_id) REFERENCES groupslist (group_id) LABEL lmember PROPERTIES ALL COLUMNS   ); Last command fails with error: ERROR: property "name" data type modifier mismatch: 19 vs. 14 DETAIL: In a property graph, a property of the same name has to have the same type modifier in each label. Labels luser and lgroup both have property "name" originated from tables userslist and groupslist with types VARCHAR(40) and VARCHAR(30). Current implementation treats them as fields with different types. I think, they should not be treated as different types. Typmod is additional constrain, it does not create another type. Documentation includes:"modifiers, that is optional constraints attached to a type declaration, such as char(5) or numeric(30,2)" Operations with values using different typmod do not require cast, they treated as the same type. Also I would add, that Oracle executes the code above without error. I propose to exclude the check of typmod from the equivalence of types check in src/backend/commands/propgraphcmds.c . I suppose there is other reason to make this check (not the Standart SQL-2023 requirement, but internal dependency), but I have not realised this reason. -- Best regards, Vladlen Popolitov.