On Wed, Oct 31, 2018 at 01:30:52PM -0400, Robert Haas wrote: > In theory, at least, you could write C code to scan the catalog tables > with SnapshotDirty to find the catalog entries, but I don't think that > helps a whole lot. You couldn't necessarily rely on those catalog > entries to be in a consistent state, and even if they were, they might > depend on committed types or functions or similar whose definitions > your backend can't see. Moreover, the creating backend will have an > AccessExclusiveLock on the table -- if you write C code to bypass that > and read the data anyway, then you will probably destabilize the > entire system for complicated reasons that I don't feel like > explaining right now.
One take here is that we cannot give any guarantee that a single DDL will create only one consistent version of the tuple added in system catalogs. In those cases a new version is made visible by using CommandCounterIncrement() so as the follow-up processing can see it.
> You should try very hard to find some way of solving this problem that > doesn't require reading data from a table that hasn't been committed > yet, because you are almost certainly not going to be able to make > that work reliably even if you are willing to write code in C.
