Re: SQL Property Graph Queries (SQL/PGQ) - Mailing list pgsql-hackers

From Vladlen Popolitov
Subject Re: SQL Property Graph Queries (SQL/PGQ)
Date
Msg-id ec97368444e41688bbbfcb5dd6a1663b@postgrespro.ru
Whole thread Raw
In response to Re: SQL Property Graph Queries (SQL/PGQ)  (Junwang Zhao <zhjwpku@gmail.com>)
Responses Re: SQL Property Graph Queries (SQL/PGQ)
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Nisha Moond
Date:
Subject: Re: Conflict detection for multiple_unique_conflicts in logical replication
Next
From: Dmitry Dolgov
Date:
Subject: Re: Changing shared_buffers without restart