Hey again Jim,
Sorry for the long pause on this.
I was thinking about the idea of managing the catalogs for read and write, and I'm coming around to the idea of predefined roles after all. Relying on conventional namespace-level ACLs for this turns out to be impractical. With the normal ACL, a schema is object agnostic, so there's no clean way to selectively restrict XML schema creation without also affecting other objects in the sam enamespace. A simple scenario like limiting who can write already gets messy. I did consider RLS on the catalog, but that would be unprecedented for a pg_* table and would break assumptions throughout the system, like pg_dump, dependency tracking, syscache lookups... blah!
That said, I'd like to hear from more people on this before committing to an approach, assuming there's still legitimate interest in moving this work forward.
On the potential CPU burn from validation: I think in practice it's comparable to what you'd get from a complex index, heavy check constraint, or trigger function. However, the nature of the input (and I mean the XML schema definitions as plain text here), likely coming from the application layer, sets a warrant for extra caution I guess. Limiting the depth and size of both the schema and the document being validated would reduce compatibility, but goes a long way in preventing resource exhaustion, so it's a fairly trivial option to implement.
I tested the changes on my own instance with Cirrus, so it might be the case of the version mismatch indeed. I simply reattached both as v6 once again (no changes, still working on master).
Regards, Marcos.
