On Thu, Sep 10, 2026 at 3:24 AM Ashutosh Bapat <[email protected]> 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=hnd...@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
