MIME-Version: 1.0
References: 
 <CAN3aFCdx8AapWSVpJ1kaC7OC_v7QwbjgbGw9WfPBBY2GMyOadQ@mail.gmail.com>
 <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>
 <CAFj8pRB3d_fREmgzT1GQwG_wfR1brxyTMVsAV=bbpOzvPkauLg@mail.gmail.com>
 <de6dade3-4956-4b57-b51d-1db703e16702@uni-muenster.de>
In-Reply-To: <de6dade3-4956-4b57-b51d-1db703e16702@uni-muenster.de>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Tue, 31 Mar 2026 12:57:49 +0200
Message-ID: 
 <CAFj8pRBg6bbO4YiSO633RHMOqQ3jAtVtCq=oN8TPE2FHG9LY2Q@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="000000000000cbf23b064e4fd826"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFj8pRBg6bbO4YiSO633RHMOqQ3jAtVtCq%3DoN8TPE2FHG9LY2Q%40mail.gmail.com>
Precedence: bulk

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

=C3=BAt 31. 3. 2026 v 11:29 odes=C3=ADlatel Jim Jones <jim.jones@uni-muenst=
er.de>
napsal:

>
>
> On 30/03/2026 22:28, Pavel Stehule wrote:
> > 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.
>
> +1
>
> > 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.
>
> I wonder what are the applications for this 1:N relationship between xml
> schemas and their identifiers. Sounds cool though.
>

I found
https://www.developpez.net/forums/d540201/bases-donnees/db2/validation-xml-=
db2-v9-5-a/


> > 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.
>
>
> A few other things I noticed in v6
>
> =3D=3D event triggers (event_trigger.c) =3D=3D
>
> OBJECT_XMLSCHEMA is in the elog(ERROR) path of stringify_grant_objtype()
> and stringify_adefprivs_objtype(). Since the grammar does support
> GRANT/REVOKE ... ON XMLSCHEMA, any event trigger on ddl_command_end that
> fires during a GRANT on an XML schema will raise a elog(ERROR,
> "unsupported object type").
>
> An additional test here would be nice as well.
>
> =3D=3D corrupt dump =3D=3D
>
> pg_dump is ignoring GRANT statements. Since the feature supports
> GRANT/REVOKE on XMLSCHEMAS, omitting ACL dump means privileges are
> silently lost during dump/restore.
>
> =3D=3D inconsistent DDL statements =3D=3D
>
> The docs suggest that ALTER XMLSCHEMA ... IF EXISTS is supported, which
> isn't the case. It should be either implemented or just removed from the
> docs.
>
> =3D=3D different error message for build without libxml =3D=3D
>
> In xml.c the error messag used is "unsupported XML feature", but you're
> using "xmlschema support requires libxml" in pg_xmlschema.c. I think we
> should be consistent here.
>
> Thanks!
>
> Best, Jim
>
>
>
>

--000000000000cbf23b064e4fd826
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">=C3=BAt 31. 3. =
2026 v=C2=A011:29 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><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 30/03/2026 22:28, Pavel Stehule wrote:<br>
&gt; I checked db2 doc, and if I understand their doc, the XML schema is<br=
>
&gt; identified by &quot;relational identifier&quot; SQLschema.name<br>
&gt; <br>
&gt; So taking XML schema as catalog object is the correct analogy and usin=
g<br>
&gt; acl looks to me correct.<br>
<br>
+1<br>
<br>
&gt; But what is different (patch and db2), one relational identifier can<b=
r>
&gt; identify a group of XML schemas. So there is relation 1:N not 1:1. You=
<br>
&gt; can see the REGISTER XMLSCHEMA command.<br>
<br>
I wonder what are the applications for this 1:N relationship between xml<br=
>
schemas and their identifiers. Sounds cool though.<br></blockquote><div><br=
></div>I found <a href=3D"https://www.developpez.net/forums/d540201/bases-d=
onnees/db2/validation-xml-db2-v9-5-a/">https://www.developpez.net/forums/d5=
40201/bases-donnees/db2/validation-xml-db2-v9-5-a/</a></div><div class=3D"g=
mail_quote gmail_quote_container"><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">
<br>
&gt; The schema registration is different on MSSQL where it is more similar=
<br>
&gt; to some local cache, and schema is identified only by uri. In this cas=
e<br>
&gt; using ACL can be messy, and I can imagine having some dedicated role<b=
r>
&gt; that can register=C2=A0a new xml schema. But MSSQL doesn&#39;t support=
 SQL/XML<br>
&gt; XMLVALIDATE function.<br>
&gt; <br>
&gt; Both concepts are workable, and I have no strong preference for one or=
<br>
&gt; second (maybe DB2 concept is better for Postgres, probably DB2 concept=
<br>
&gt; is closer to SQL/XML). But if we use relational identifiers, then it<b=
r>
&gt; should be consistent with other usage of relational identifiers - ther=
e<br>
&gt; ACL should be used.<br>
<br>
<br>
A few other things I noticed in v6<br>
<br>
=3D=3D event triggers (event_trigger.c) =3D=3D<br>
<br>
OBJECT_XMLSCHEMA is in the elog(ERROR) path of stringify_grant_objtype()<br=
>
and stringify_adefprivs_objtype(). Since the grammar does support<br>
GRANT/REVOKE ... ON XMLSCHEMA, any event trigger on ddl_command_end that<br=
>
fires during a GRANT on an XML schema will raise a elog(ERROR,<br>
&quot;unsupported object type&quot;).<br>
<br>
An additional test here would be nice as well.<br>
<br>
=3D=3D corrupt dump =3D=3D<br>
<br>
pg_dump is ignoring GRANT statements. Since the feature supports<br>
GRANT/REVOKE on XMLSCHEMAS, omitting ACL dump means privileges are<br>
silently lost during dump/restore.<br>
<br>
=3D=3D inconsistent DDL statements =3D=3D<br>
<br>
The docs suggest that ALTER XMLSCHEMA ... IF EXISTS is supported, which<br>
isn&#39;t the case. It should be either implemented or just removed from th=
e<br>
docs.<br>
<br>
=3D=3D different error message for build without libxml =3D=3D<br>
<br>
In xml.c the error messag used is &quot;unsupported XML feature&quot;, but =
you&#39;re<br>
using &quot;xmlschema support requires libxml&quot; in pg_xmlschema.c. I th=
ink we<br>
should be consistent here.<br>
<br>
Thanks!<br>
<br>
Best, Jim<br>
<br>
<br>
<br>
</blockquote></div></div>

--000000000000cbf23b064e4fd826--