Re: WIP - xmlvalidate implementation from TODO list - Mailing list pgsql-hackers

From Marcos Magueta
Subject Re: WIP - xmlvalidate implementation from TODO list
Date
Msg-id CAN3aFCdW3_RNgidcV_vWA-NFeYf6p7M5VMG8moSzk3bBJneUxQ@mail.gmail.com
Whole thread Raw
In response to Re: WIP - xmlvalidate implementation from TODO list  (Jim Jones <jim.jones@uni-muenster.de>)
Responses Re: WIP - xmlvalidate implementation from TODO list
List pgsql-hackers
Hello there again, Jim!

Here's the v6 with the docs updated and some minor things. I have questions about the predefined roles however.

The tab completion on psql was using the wrong OID type, so I took the chance to change it to only complete unqualified XML schemas in current_schemas with true.

I noticed I had added a change I made to run locally on pg_regress that shouldn't be on the patch, so I reversed it (execl to execlp because of NixOS search paths).

I was trying to figure out how to do the roles, and I have some thoughts on it now. While I am not particularly against predefined roles, I think we should be careful before committing to them in this form. As predefined roles, they would effectively become part of a long-term public interface: once they exist, we should then carry them forward and preserve their semantics across releases, so adding a feature-specific role increases permanent surface area (docs, tests, upgrade behavior, compatibility expectations) and is harder to revisit later if the privilege model evolves (which I think will make people mad, it's XML burden after all).

Also, a write-oriented role is not as straightforward as I thought with the current ownership model (and that's me guessing here). Mutating DDL behavior is still owner-driven (or superuser-driven) most of the places, not purely ACL-driven, so a pg_write_xmlschemas role can look clearer at first glance than it is in practice. To make that role fully consistent, we may need broader policy decisions around what should be grantable versus what should remain ownership-based, not just new role entries. Again, I am not opposed to the idea, but these made me a bit anxious to simply add them. What are your thoughts on these?

PS: Reattached patch 2 as v5 just to make it easier to get everything, but nothing changed in there.

Regards,
Marcos Magueta.
Attachment

pgsql-hackers by date:

Previous
From: Zsolt Parragi
Date:
Subject: Re: centralize CPU feature detection
Next
From: Fabrízio de Royes Mello
Date:
Subject: Re: convert SpinLock* macros to static inline functions