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: Sun, 15 Mar 2026 16:20:42 +0100
Message-ID: 
 <CAFj8pRDmszE0BCO1XsoAJVEj4uB6hWa9H2TBhV0yhatf_fz1xg@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="000000000000760497064d11a710"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFj8pRDmszE0BCO1XsoAJVEj4uB6hWa9H2TBhV0yhatf_fz1xg%40mail.gmail.com>
Precedence: bulk

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

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 have no opinion about this now.  I need to read both variants.

>
> Best, Jim
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">ne 15. 3. 2026 =
v=C2=A013:58 odes=C3=ADlatel Jim Jones &lt;<a href=3D"mailto:jim.jones@uni-=
muenster.de">jim.jones@uni-muenster.de</a>&gt; napsal:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,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><div><br></div><div>I have no opin=
ion about this now.=C2=A0 I need to read both variants.</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">
<br>
Best, Jim<br>
</blockquote></div></div>

--000000000000760497064d11a710--