MIME-Version: 1.0
References: 
 <CAN3aFCdx8AapWSVpJ1kaC7OC_v7QwbjgbGw9WfPBBY2GMyOadQ@mail.gmail.com>
 <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>
 <CAFj8pRBg6bbO4YiSO633RHMOqQ3jAtVtCq=oN8TPE2FHG9LY2Q@mail.gmail.com>
 <d8b8cd5c-dc01-40b2-8eb9-edbc0d6fbbf2@uni-muenster.de>
 <CAFj8pRBq4580f5n7DTe7x+SWqCS_d=e1Of7snUNaKk8_L1g28Q@mail.gmail.com>
 <f185992f-a566-4174-a3a8-fbf4b9d04ea3@uni-muenster.de>
In-Reply-To: <f185992f-a566-4174-a3a8-fbf4b9d04ea3@uni-muenster.de>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Wed, 1 Apr 2026 18:57:24 +0200
Message-ID: 
 <CAFj8pRDEOmkafV3s7XjCK-DzvnhoxgvHWJ7tChUi=-8zJ20Vog@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="0000000000009486c6064e68fc51"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFj8pRDEOmkafV3s7XjCK-DzvnhoxgvHWJ7tChUi%3D-8zJ20Vog%40mail.gmail.com>
Precedence: bulk

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

st 1. 4. 2026 v 16:39 odes=C3=ADlatel Jim Jones <jim.jones@uni-muenster.de>
napsal:

>
>
> On 01.04.26 10:10, Pavel Stehule wrote:
> > maybe it can be implemented just as an extension - we don't need DDL
> > commands CREATE XMLSCHEMA - there can be some function. If I understand
> > correctly, the SQL/XML knows just XMLVALIDATE command - and in the firs=
t
> > step - this can be just a function too.
>
> Yeah, the spec does not dictate how the schemas are stored or how
> identifiers are mapped to XSDs. The way I see it, in the current state
> of this patch, we miss the option to add XSDs to an existing XMLSCHEMA
> identifier (something like ALTER XMLSCHEMA .. ADD ...), or even the
> option to pass multiple XSDs in CREATE XMLSCHEMA.
>
> It makes the implementation of CREATE XMLSCHEMA (or similar DDL) a bit
> more challenging, as it must always resolve all root's dependencies to
> ensure that XMLVALIDATE has all the necessary info to validate a given XM=
L.
>
> >
> > Theoretically there can be different access - we can introduce a generi=
c
> > XMLVALIDATE command, that can call some callback. This callback can be
> > implemented in an extension. One extension can XML storage identified b=
y
> > relation identifier, another can implement some shared storage on the
> > disc outside the database etc. So the organization of the patch can be
> > different
> >
> > 1. creating API for extensions for implementing loading the schema from
> > some sources.
> > 2. implementation XMLVALIDATE that uses this API
> > 3. creating an extension in contrib, that implements XML storage
> > identified by relational API.
> >
> > Because we don't have an extensible parser, the XMLVALIDATE command
> > should be in core, but other parts are not.
>
>
> How would XMLVALIDATE without this contrib extension look like?
>

The API can be similar to PLpgSQL plugin API - and rendezvous variable

Pavel

>
> Best, Jim
>

--0000000000009486c6064e68fc51
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">st 1. 4. 2026 v=
=C2=A016:39 odes=C3=ADlatel Jim Jones &lt;<a href=3D"mailto:jim.jones@uni-m=
uenster.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 sol=
id rgb(204,204,204);padding-left:1ex"><br>
<br>
On 01.04.26 10:10, Pavel Stehule wrote:<br>
&gt; maybe it can be implemented just as an extension - we don&#39;t need D=
DL<br>
&gt; commands CREATE XMLSCHEMA - there can be some function. If I understan=
d<br>
&gt; correctly, the SQL/XML knows just XMLVALIDATE command - and in the fir=
st<br>
&gt; step - this can be just a function too.=C2=A0<br>
<br>
Yeah, the spec does not dictate how the schemas are stored or how<br>
identifiers are mapped to XSDs. The way I see it, in the current state<br>
of this patch, we miss the option to add XSDs to an existing XMLSCHEMA<br>
identifier (something like ALTER XMLSCHEMA .. ADD ...), or even the<br>
option to pass multiple XSDs in CREATE XMLSCHEMA.<br>
<br>
It makes the implementation of CREATE XMLSCHEMA (or similar DDL) a bit<br>
more challenging, as it must always resolve all root&#39;s dependencies to<=
br>
ensure that XMLVALIDATE has all the necessary info to validate a given XML.=
<br>
<br>
&gt; <br>
&gt; Theoretically there can be different access - we can introduce a gener=
ic<br>
&gt; XMLVALIDATE command, that can call some callback. This callback can be=
<br>
&gt; implemented in an extension. One extension can XML storage identified =
by<br>
&gt; relation identifier, another can implement some shared storage on the<=
br>
&gt; disc outside the database etc. So the organization of the patch can be=
<br>
&gt; different=C2=A0<br>
&gt; <br>
&gt; 1. creating API for extensions for implementing loading the schema fro=
m<br>
&gt; some sources.<br>
&gt; 2. implementation XMLVALIDATE that uses this API<br>
&gt; 3. creating an extension in contrib, that implements XML storage<br>
&gt; identified by relational API.<br>
&gt; <br>
&gt; Because we don&#39;t have an extensible parser, the XMLVALIDATE comman=
d<br>
&gt; should be in core, but other parts are not.<br>
<br>
<br>
How would XMLVALIDATE without this contrib extension look like?<br></blockq=
uote><div><br></div><div>The API can be similar to PLpgSQL plugin API - and=
 rendezvous variable</div><div><br></div><div>Pavel=C2=A0=C2=A0</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>
Best, Jim<br>
</blockquote></div></div>

--0000000000009486c6064e68fc51--