MIME-Version: 1.0
References: <CAN3aFCdx8AapWSVpJ1kaC7OC_v7QwbjgbGw9WfPBBY2GMyOadQ@mail.gmail.com>
 <CALdSSPjxLU+zhWx+CgwN+VHoHTso33trY6mse1A6Jks7hWAdrA@mail.gmail.com>
 <CAN3aFCesNDiL-iZg4imC0n+NgT3JywqZYkuGH83u8ssLjJ-p5Q@mail.gmail.com>
 <CAN3aFCfvVgXr77o=dB_E2kSCY+EgckSQbSBdd_N9n-LauWuQLw@mail.gmail.com>
 <CAN3aFCcx_w5Ldb+SYurwd31es9hOJqLuKARQHHDOk7+5iOqBWQ@mail.gmail.com>
 <CALdSSPhFzYCp=Aa8AAboz6TQaTmjWciQGfrEJQeOOO+0pD1GGw@mail.gmail.com>
 <89DE974B-F318-4D0A-A60B-51EDE84054E2@gmail.com> <9A074422-2308-4BD0-9FFA-0B6D70989935@yandex-team.ru>
 <70c72cb1-a39f-41b3-bfe3-e32ee7fda9c4@uni-muenster.de>
In-Reply-To: <70c72cb1-a39f-41b3-bfe3-e32ee7fda9c4@uni-muenster.de>
From: Marcos Magueta <maguetamarcos@gmail.com>
Date: Mon, 5 Jan 2026 14:49:47 -0300
Message-ID: <CAN3aFCfdGp6TGTQNOVO1im1u2vO_E2jnTGVV2xhea7eNY7GtuQ@mail.gmail.com>
Subject: Re: WIP - xmlvalidate implementation from TODO list
To: Jim Jones <jim.jones@uni-muenster.de>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, Kirill Reshke <reshkekirill@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000000ea6020647a7b0a8"
Archived-At: <https://www.postgresql.org/message-id/CAN3aFCfdGp6TGTQNOVO1im1u2vO_E2jnTGVV2xhea7eNY7GtuQ%40mail.gmail.com>
Precedence: bulk

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

Thank you all for the careful review!

I'll go through the topics to fix the test and code changes today, but I
have a couple of questions about a catalog.

If we were to implement a catalog, I believe it would be either copying an
insert to a specified relation (created on demand) or to something in the
catalog, like pg_xmlschema. That could be a realistic change I could work
on. But what about the privilege level and file fetch support? I believe
it's not really an issue if the user is sufficiently privileged, so should
it mirror COPY FROM? I haven't seen its implementation, but I suppose it
already has security checks at the user privilege level. A valid
alternative to not deal with privileges and to leave the same restrictions
already in place to fetch arbitrary extensions to a specified schema; in
that way we are just moving the schema definition to another command before
being invoked and ignoring if it has any references outside of the plain
text specified (therefore, not using file://, like IBM, just text).

Surprisingly, the standard (I only have the 2016 here) leaves a great room
for freedom on how to implement the registration. It just specifies what it
should have:

An XML namespace NS contained in a registered XML Schema is
non-deterministic if NS contains a global
element declaration schema component that is non-deterministic.
A registered XML Schema is non-deterministic if it contains a
non-deterministic XML namespace.
A registered XML Schema is described by a registered XML Schema descriptor.
A registered XML Schema
descriptor includes:
=E2=80=94 The target namespace URI of the registered XML Schema.
=E2=80=94 The schema location URI of the registered XML Schema.
=E2=80=94 The <registered XML Schema name> of the registered XML Schema.
=E2=80=94 An indication of whether the registered XML Schema is permanently
registered.
=E2=80=94 An indication of whether the registered XML Schema is non-determi=
nistic.
=E2=80=94 An unordered collection of the namespaces defined by the register=
ed XML
Schema (the target namespace
is one of these namespaces).
=E2=80=94 For each namespace defined by the registered XML Schema, an unord=
ered
collection of the global element
declaration schema components in that namespace, with an indication for
each global element declaration
schema component whether that global element declaration schema component
is non-deterministic.
NOTE 9 =E2=80=94 Without Feature X161, =E2=80=9CAdvanced Information Schema=
 for registered
XML Schemas=E2=80=9D, information whether an XML
Schema is deterministic, information about the collection of namespaces
defined in that XML Schema, and, for each such namespace
information about the global element declaration schema components in that
namespace, is not available in the XML_SCHEMAS,
XML_SCHEMA_NAMESPACES, and XML_SCHEMA_ELEMENTS views.
A registered XML Schema is identified by its <registered XML Schema name>.

I am tempted to go with a pg_xmlschema definition on the catalog and an
interface like the one IBM has, but still restricting file access. Dealing
with the security problems for that sounds excruciating. Any opinions?

Regards, Magueta.

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

<div dir=3D"ltr"><div><div><div>Thank you all for the careful review!<br><b=
r></div>I&#39;ll go through the topics to fix the test and code changes tod=
ay, but I have a couple of=C2=A0questions about a catalog.<br><br></div>If =
we were to implement a catalog, I believe it would be either copying an ins=
ert to a=C2=A0specified=C2=A0relation (created on demand) or to something i=
n the catalog, like pg_xmlschema. That could be a realistic change I could =
work on. But what about the privilege level and file fetch support? I belie=
ve it&#39;s not really an issue if the user is sufficiently privileged, so =
should it mirror COPY FROM? I haven&#39;t seen its implementation, but I su=
ppose it already has security checks at the user privilege level. A valid a=
lternative to not deal with privileges and to leave the same restrictions a=
lready in place to fetch arbitrary extensions to a specified schema; in tha=
t way we are just moving the schema definition to another command before be=
ing invoked and ignoring if it has any references outside of the plain text=
 specified (therefore, not using file://, like IBM, just text).<br><br></di=
v><div>Surprisingly, the standard (I only have the 2016 here) leaves a grea=
t room for freedom on how to implement the registration. It just specifies =
what it should have:<br><br><div style=3D"margin-left:40px">An XML namespac=
e NS contained in a registered XML Schema is non-deterministic if NS contai=
ns a global<br>element declaration schema component that is non-determinist=
ic.<br>A registered XML Schema is non-deterministic if it contains a non-de=
terministic XML namespace.<br>A registered XML Schema is described by a reg=
istered XML Schema descriptor. A registered XML Schema<br>descriptor includ=
es:<br>=E2=80=94 The target namespace URI of the registered XML Schema.<br>=
=E2=80=94 The schema location URI of the registered XML Schema.<br>=E2=80=
=94 The &lt;registered XML Schema name&gt; of the registered XML Schema.<br=
>=E2=80=94 An indication of whether the registered XML Schema is permanentl=
y registered.<br>=E2=80=94 An indication of whether the registered XML Sche=
ma is non-deterministic.<br>=E2=80=94 An unordered collection of the namesp=
aces defined by the registered XML Schema (the target namespace<br>is one o=
f these namespaces).<br>=E2=80=94 For each namespace defined by the registe=
red XML Schema, an unordered collection of the global element<br>declaratio=
n schema components in that namespace, with an indication for each global e=
lement declaration<br>schema component whether that global element declarat=
ion schema component is non-deterministic.<br>NOTE 9 =E2=80=94 Without Feat=
ure X161, =E2=80=9CAdvanced Information Schema for registered XML Schemas=
=E2=80=9D, information whether an XML<br>Schema is deterministic, informati=
on about the collection of namespaces defined in that XML Schema, and, for =
each such namespace<br>information about the global element declaration sch=
ema components in that namespace, is not available in the XML_SCHEMAS,<br>X=
ML_SCHEMA_NAMESPACES, and XML_SCHEMA_ELEMENTS views.<br>A registered XML Sc=
hema is identified by its &lt;registered XML Schema name&gt;.<br></div><br>=
</div><div>I am tempted to go with a pg_xmlschema definition on the catalog=
 and an interface like the one IBM has, but still restricting file access. =
Dealing with the security problems for that sounds excruciating. Any opinio=
ns?<br><br></div><div>Regards, Magueta.</div></div>

--0000000000000ea6020647a7b0a8--