Hi, On 2026-09-02 15:29:06 -0400, Melanie Plageman wrote: > Whether there should be a pg_class entry for property graphs: > --- > Andres who posted his initial concern about this has not indicated if > the answers resolve his concern.
It does. I was really just curious why that choice was made. And I think Ashutosh's answer explains it and I think alternative ways of implementing the single-namespace would be way worse. Other than perhaps immortalizing it in a comment somewhere, not further action is needed. > Separately, though having a pg_class entry seems to buy you some > functionality for free, the bug Andrew reported where AlterPropGraph() > doesn't verify its target is a property graph feels like it may be > indicative of more problems related to code that is reading pg_class entries > and not distinguishing between graphs and tables. I think that's a serious bug, but it's also pretty easy to fix, and it's something that a lot of different places already have to have checks for. Needing to check for a specific relkind is far from unique to propgraphs. To me the concerning aspect about that omission isn't so much that it indicates an architectural issue, but that it pretty clearly indicates insufficiently reviewed code. I was looking at AlterPropGraph() while writing the above paragraphs, and it made me wonder why it'd be sufficient to use ShareRowExclusiveLock? Why is it ok to alter a propgraph fairly fundamentally while there's queries using the propgraph (with AccessShareLock, which does not conflict with ShareRowExclusiveLock)? It's obviously sometimes possible to use ShareRowExclusiveLock, but typically not for stuff that could completely invalidate concurrently running queries, and changing the schema of a propgraph by dropping vertex/edges certainly seems like it would? Greetings, Andres Freund
