Hey Jim and Pavel, thanks for demonstrating interest.
> XML is a little bit outdated - but the proposed infrastructure can be used for any documents, so it can theoretically supports json, jsonb too [...]. I expect something like XMLVALIDATE will be JSON standard in a few years.
That doesn't sound like a bad idea to me. But I suspect I would need to almost completely revamp the implementation in the patch so far, so I would like to confirm a few things before committing to anything on that front.
It is usual when you design a feature that is not fully described by standard :-/. And then it is good to start primary from part (command), that is well described by standard.
I am still unsure how the permissions would be managed properly with the API approach. It seems to me we could rely on the ACL like before, but I sense there's something more arcane around it when it comes to the extension.
There are two different things - 1. possibility to registrate xml schema - you need just to CREATE right for related pg_namespace, 2. possibility to use xml schema - and you need to USAGE right - and this can be checked inside extension. Probably you cannot use all ACL related macros, and maybe you have to design some function instead of GRANT and REVOKE. Maybe some form of RLS can be used. When you separate storage of XML schemas to an extension, then you can implement just some minimalistic implementation (just what is necessary for regress tests) - and some more complex storage of XML schema can be designed (developed) outside the main branch. Hypothetical storage from contrib can be enhanced step by step.
Regards
Pavel
I didn't realize, but DB2 actually gives you decomposition over an xml hierarchy into tables, which is an insanely valuable feature. I wonder how we could go with that here using the current catalog approach.
Is there anything else that might be troublesome with changing approaches?
