property graph and pg_dump

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: property graph and pg_dump
Date: 2026-09-15 06:42:55
Message-ID: CAExHW5tQWFV=zahj_tzGcjTfbkW6_esP8zuQJmZfAoMQZOcWVw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi All,
in [1] we discussed many issues related to SQL/PGQ. A couple of issues
were related to pg_dump. Starting a new thread here to discuss those.
For now, I am expecting to discuss ideas and interpretation of
relevant clauses from SQL/PGQ standard. I am expecting that we defer
the discussion of actual implementation till SQL/PGQ work is proposed
again.

1. getDependencies() transferred depencies of pg_propgraph_element
entries to the parent property graph but missed doing so for
pg_propgraph_property and pg_propgraph_label_property. One of the
symptoms of this omission is seen as a failure to restore a property
graph which has a property with a table's row type as its data type.
Table's row type depends upon the table which has the same dump
priority as the property graph. Without an appropriate dependency
transfer, the property graph may get dumped before the table.

A better fix might be to dump each property graph element separately.
According SQL/PGQ standard sections 11.5, 11.7 to 11.18, if a property
graph component (a property expression or an element table or
expression therein) depends upon an external object which is being
dropped, the property graph element containing that component should
be dropped. Thus the dependency of a property graph component should
be registered as a normal dependency from the property graph element/s
to the external object. Once we register the dependency this way, the
elements of the property graph will be ordered to be dumped after
their dependencies. Thus we can get rid of special handling of
property graph components in getDependencies() entirely. An idea worth
exploring.

2. An allied issue: Quoting Andres: "I think it's already pretty weird
that views are created as part of dumpTableSchema(), but they at least
share some infrastructure with tables. I don't see any reason for
propgraphs to not have been redirected in dumpTable(), just like it's
done for dumpSequence()?". That's a possibility worth exploring.

3. A related issue is the presence of pg_attribute entries for a
property graph. Those are not needed and they are not used anywhere.
They shouldn't be added in the first place.

--
Best Wishes,
Ashutosh Bapat

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexandre Felipe 2026-09-15 06:49:31 FIX: BUG #19687: ALTER SEQUENCE missing lock
Previous Message Chao Li 2026-09-15 05:56:17 Re: pg_createsubscriber does not check output_plugin_libraries