MIME-Version: 1.0
References: 
 <CAN3aFCdx8AapWSVpJ1kaC7OC_v7QwbjgbGw9WfPBBY2GMyOadQ@mail.gmail.com>
 <CAN3aFCc2voQ=6+Nwy99NFJZwveYmwtCKAj6U9RhjxqQc25+Q_g@mail.gmail.com>
 <2898f090-d9cf-475c-940c-a99da4a308f1@uni-muenster.de>
 <CAN3aFCcUFLbdVBoL6c2bMh4r5P9EnXM9eBsX8+ZyER7YBSDUtA@mail.gmail.com>
 <08052569-9384-41b5-bcb7-33929fcc6c71@uni-muenster.de>
 <cfd2c12a-41fb-4a8b-9b14-390e53f4c898@uni-muenster.de>
 <ccc35098-a93c-4510-abd9-71d395acdba5@uni-muenster.de>
 <CAN3aFCecpcPBs4x3KUuxTqvY2VzpCZZKrBphNaQjE5uD8UtEpQ@mail.gmail.com>
 <CAN3aFCcb0Nvap1CKShd5RNa+V+pray+ur_LtOON3nkwqdh5NMA@mail.gmail.com>
 <2ba05acc-6392-42a4-b59e-61df086b2d4d@uni-muenster.de>
 <CAN3aFCdW3_RNgidcV_vWA-NFeYf6p7M5VMG8moSzk3bBJneUxQ@mail.gmail.com>
 <1d49e214-93bc-4928-945c-27e60251a6ad@uni-muenster.de>
 <CAN3aFCfkrkOJ+R39x=9qvXMGLE3yuL9fZdNyRa5V=BAdGGu=-g@mail.gmail.com>
 <9228b6dc-cfae-4a11-927a-209680f5507e@uni-muenster.de>
 <CAN3aFCcvXHmW+FKS7gX=HoUcjku2nr7XKJEZm05DrgsQxy79HQ@mail.gmail.com>
 <2f8ca841-0956-4e7d-8fa2-038b879c8f4d@uni-muenster.de>
In-Reply-To: <2f8ca841-0956-4e7d-8fa2-038b879c8f4d@uni-muenster.de>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Mon, 30 Mar 2026 22:28:39 +0200
Message-ID: 
 <CAFj8pRB3d_fREmgzT1GQwG_wfR1brxyTMVsAV=bbpOzvPkauLg@mail.gmail.com>
Subject: Re: WIP - xmlvalidate implementation from TODO list
To: Jim Jones <jim.jones@uni-muenster.de>
Cc: Marcos Magueta <maguetamarcos@gmail.com>,
 Andrey Borodin <x4mmm@yandex-team.ru>,
	Kirill Reshke <reshkekirill@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000688930064e43b482"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFj8pRB3d_fREmgzT1GQwG_wfR1brxyTMVsAV%3DbbpOzvPkauLg%40mail.gmail.com>
Precedence: bulk

--000000000000688930064e43b482
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi

ne 15. 3. 2026 v 13:58 odes=C3=ADlatel Jim Jones <jim.jones@uni-muenster.de=
>
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 withou=
t
> > 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 checked db2 doc, and if I understand their doc, the XML schema is
identified by "relational identifier" SQLschema.name

So taking XML schema as catalog object is the correct analogy and using acl
looks to me correct.

But what is different (patch and db2), one relational identifier can
identify a group of XML schemas. So there is relation 1:N not 1:1. You can
see the REGISTER XMLSCHEMA command.

The schema registration is different on MSSQL where it is more similar to
some local cache, and schema is identified only by uri. In this case using
ACL can be messy, and I can imagine having some dedicated role that can
register a new xml schema. But MSSQL doesn't support SQL/XML XMLVALIDATE
function.

Both concepts are workable, and I have no strong preference for one or
second (maybe DB2 concept is better for Postgres, probably DB2 concept is
closer to SQL/XML). But if we use relational identifiers, then it should be
consistent with other usage of relational identifiers - there ACL should be
used.

Regards

Pavel


> Best, Jim
>

--000000000000688930064e43b482
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi</div><br><div class=3D"gmail_quote gmail_quote_con=
tainer"><div dir=3D"ltr" class=3D"gmail_attr">ne 15. 3. 2026 v=C2=A013:58 o=
des=C3=ADlatel Jim Jones &lt;<a href=3D"mailto:jim.jones@uni-muenster.de">j=
im.jones@uni-muenster.de</a>&gt; napsal:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">Hi Marcos<br>
<br>
On 15/03/2026 05:25, Marcos Magueta wrote:<br>
&gt; I was thinking about the idea of managing the catalogs for read and<br=
>
&gt; write, and I&#39;m coming around to the idea of predefined roles after=
 all.<br>
&gt; Relying on conventional namespace-level ACLs for this turns out to be<=
br>
&gt; impractical. With the normal ACL, a schema is object agnostic, so<br>
&gt; there&#39;s no clean way to selectively restrict XML schema creation w=
ithout<br>
&gt; also affecting other objects in the sam=C2=A0enamespace. A simple scen=
ario<br>
&gt; like limiting who can write already gets messy. I did consider RLS on<=
br>
&gt; the catalog, but that would be unprecedented for a pg_* table and woul=
d<br>
&gt; break assumptions throughout the system, like pg_dump, dependency<br>
&gt; tracking, syscache lookups... blah!<br>
&gt; <br>
&gt; That said, I&#39;d like to hear from more people on this before commit=
ting<br>
&gt; to an approach, assuming there&#39;s still legitimate interest in movi=
ng<br>
&gt; this work forward.<br>
<br>
<br>
I guess we can assume that everything added to the official todo list is<br=
>
of interest for the community -- at least I do :).<br>
<br>
<br>
&gt; On the potential CPU burn from validation: I think in practice it&#39;=
s<br>
&gt; comparable to what you&#39;d get from a complex index, heavy check<br>
&gt; constraint, or trigger function. However, the nature of the input (and=
 I<br>
&gt; mean the XML schema definitions as plain text here), likely coming fro=
m<br>
&gt; the application layer, sets a warrant for extra caution I guess.<br>
&gt; Limiting the depth and size of both the schema and the document being<=
br>
&gt; validated would reduce compatibility, but goes a long way in preventin=
g<br>
&gt; resource exhaustion, so it&#39;s a fairly trivial option to implement.=
<br>
<br>
<br>
I took the liberty to add Pavel to this thread. He has way more<br>
experience than me in this part of the code, and perhaps he can share<br>
his opinion on the predefined roles for XML schemas and his impressions<br>
on the patch as a whole.<br></blockquote><br></div><div class=3D"gmail_quot=
e gmail_quote_container">I checked db2 doc, and if I understand their doc, =
the XML schema is identified by &quot;relational identifier&quot; SQLschema=
.name</div><div class=3D"gmail_quote gmail_quote_container"><br></div><div =
class=3D"gmail_quote gmail_quote_container">So taking XML schema as catalog=
 object is the correct analogy and using acl looks to me correct.</div><div=
 class=3D"gmail_quote gmail_quote_container"><br></div><div class=3D"gmail_=
quote gmail_quote_container">But what is different (patch and db2), one rel=
ational identifier can identify a group of XML schemas. So there is relatio=
n 1:N not 1:1. You can see the REGISTER XMLSCHEMA command.</div><div class=
=3D"gmail_quote gmail_quote_container"><br></div><div class=3D"gmail_quote =
gmail_quote_container">The schema registration is different on MSSQL where =
it is more similar to some local cache, and schema is identified only by ur=
i. In this case using ACL can be messy, and I can imagine having some dedic=
ated role that can register=C2=A0a new xml schema. But MSSQL doesn&#39;t su=
pport SQL/XML XMLVALIDATE function.</div><div class=3D"gmail_quote gmail_qu=
ote_container"><br></div><div class=3D"gmail_quote gmail_quote_container">B=
oth concepts are workable, and I have no strong preference for one or secon=
d (maybe DB2 concept is better for Postgres, probably DB2 concept is closer=
 to SQL/XML). But if we use relational identifiers, then it should be consi=
stent with other usage of relational identifiers - there ACL should be used=
.</div><div class=3D"gmail_quote gmail_quote_container"><br></div><div clas=
s=3D"gmail_quote gmail_quote_container">Regards</div><div class=3D"gmail_qu=
ote gmail_quote_container"><br></div><div class=3D"gmail_quote gmail_quote_=
container">Pavel</div><div class=3D"gmail_quote gmail_quote_container"><br>=
</div><div class=3D"gmail_quote gmail_quote_container"><br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">
<br>
Best, Jim<br>
</blockquote></div></div>

--000000000000688930064e43b482--