ne 15. 3. 2026 v 13:58 odesÃlatel Jim Jones <[email protected]> napsal:
> Hi Marcos > > On 15/03/2026 05:25, Marcos Magueta wrote: > > 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. > > > I guess we can assume that everything added to the official todo list is > of interest for the community -- at least I do :). > > > > 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 took the liberty to add Pavel to this thread. He has way more > experience than me in this part of the code, and perhaps he can share > his opinion on the predefined roles for XML schemas and his impressions > on the patch as a whole. > I have no opinion about this now. I need to read both variants. > > Best, Jim >
