Re: PGQ catalog representation and pg_dump support

On Thu, Sep 10, 2026 at 3:24 AM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> Once the proper dependencies (after they are fixed) are in place , the
> metadata of the element tables needed for rewriting the GRAPH_TABLE
> can not be altered because of dependencies. E.g. changing column type
> results in an error. I couldn't reproduce any hazards in this area.

I'm kind of doubtful about this. I think that it may be true in simple
cases but not more complex ones. If you try to drop an object upon
which there is a dependency, that will get blocked, but not all
changes are barred. See the middle of this email:
http://postgr.es/m/CA+TgmoaG0sFXRKr1pA_eT-BzWhykj8tOdkmjzs2tWTK=hNdgCA@mail.gmail.com

I think the example that begins with "Or consider this example:" is a
particularly illustrative case here. It shows that, as previously
committed, "PROPERTIES ALL COLUMNS" resulted in stuff happening at
creation time based on the set of columns that existed then, and that
stuff didn't get updated if more columns were later added. No matter
what dependencies you add, nothing's going to block new columns from
being created. So this is not as simple as just "get the dependencies
right".

IMHO, the way to find bugs like this is to look at all the table
properties that are consulted when a property graph is created, and
think about what happens if those properties are changed later. If
changes are blocked by dependencies, that's fine, but a lot of changes
won't be. For a change that isn't blocked by dependencies, like say
changing the owner of one object or the other, you need to either (a)
find a way to block it via something other than the dependency
mechanism or (b) make sure that everything can tolerate the
divergence. For instance, if we create a property graph that has the
same ownership as the underlying table and then change the owner of
the table, does that break dump-and-reload? The table will have to get
created first, will get created with the new ownership, and then when
you try to create the property graph, it won't have the same owner as
the table.

This is just an example but I'm just making the point that you
shouldn't lightly dismiss the amount of work in getting all these
cases right. At least in my experience, it tends to require a pretty
significant amount of effort, and especially cases involving possible
dump-and-reload problems are easy to miss.

--
Robert Haas
EDB: http://www.enterprisedb.com