Re: PGQ catalog representation and pg_dump support

On Thu, Sep 10, 2026 at 11:10 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> 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".

I have already replied to this. Neither Section 11.11 (add column) of
SQL foundation nor section 9.12 (property graph element creation)
mandate that the PROPERTIES ALL COLUMNS implies that all the future
additions should be reflected in the property graph. But this isn't
the only case where future changes are not mandated to be reflected in
an object. A view which has a * or table.* in it, expands to the
columns that exist at the time of creation. Any column added to table
in future does not appear in view.

>
> 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.

In the particular case of ownership of the element tables, I had
expressed my concerns long back and reiterated in my response to
Andres.

Valid concerns have been raised generally in the areas of concurrency,
consistency and ownership. To the specific examples that have been
raised, I have responded with a. either accepting the bug where it is
a bug or b. quoting the relevant sections of SQL/PGQ standard.
Usually, we have followed the precedence in these areas as long as
SQL/PGQ standard agrees with those precedences. However, we have
missed considering some precedent. In this specific case, for example,
the ownership of the element tables should follow the precedence of
views: how it handles changes to the ownership of the tables it
contains. We probably missed that.

>
> 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.

Agreed. We did consider a lot of things already, and had many tests to
cover them. But we missed some.

Once SQL/PGQ work is resurrected again, it will be good to review the
work and discuss specific items.

--
Best Wishes,
Ashutosh Bapat