Subject: Re: WIP - xmlvalidate implementation from TODO list

From: Jim Jones <[email-masked]>
Date: Sun, 22 Feb 2026 12:44:01 +0100

Hi Marcos

On 22/02/2026 06:11, Marcos Magueta wrote:
>> Unfortunately, the patch no longer applies.[1]
> Trying to understand why it doesn't, we can get back to that.

I think the cfbot is confused about the ordering of your patch set. You
labelled the files as

* v5-0002-Add-XMLVALIDATE.patch
* v6-0001-Add-CREATE-XMLSCHEMA.patch

which generates two issues:

1) both of them should have the save version, i.e v5 or v6.
2) the XMLVALIDATE patch depends on CREATE XMLSCHEMA, and the files
order right now suggest quite the opposite. The next iteration should be:

* v7-0001-Add-CREATE-XMLSCHEMA.patch
* v7-0002-Add-XMLVALIDATE.patch

Best, Jim

---

From: Marcos Magueta <[email-masked]>
Date: Sun, 15 Mar 2026 01:25:22 -0300

Hey again Jim,

Sorry for the long pause on this.

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 without 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.

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 tested the changes on my own instance with Cirrus, so it might be the
case of the version mismatch indeed. I simply reattached both as v6 once
again (no changes, still working on master).

Regards, Marcos.

---

From: Pavel Stehule <[email-masked]>
Date: Sun, 15 Mar 2026 16:20:42 +0100

ne 15. 3. 2026 v 13:58 odesílatel Jim Jones <[email-masked]>
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 without
> > 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 :).
>
>
> > 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.

---

From: Pavel Stehule <[email-masked]>
Date: Mon, 30 Mar 2026 22:28:39 +0200

Hi

> his opinion on the predefined roles for XML schemas and his impressions

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

---

From: Jim Jones <[email-masked]>
Date: Tue, 31 Mar 2026 11:29:38 +0200

On 30/03/2026 22:28, Pavel Stehule wrote:
> So taking XML schema as catalog object is the correct analogy and using
> acl looks to me correct.

+1

> 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.

> 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.
> 
> 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

== event triggers (event_trigger.c) ==

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.

== corrupt dump ==

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.

== inconsistent DDL statements ==

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.

== different error message for build without libxml ==

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

---

From: Pavel Stehule <[email-masked]>
Date: Tue, 31 Mar 2026 12:57:49 +0200

> schemas and their identifiers. Sounds cool though.

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

---

From: Jim Jones <[email-masked]>
Date: Wed, 1 Apr 2026 09:47:01 +0200

On 31/03/2026 12:57, Pavel Stehule wrote:
> I found https://www.developpez.net/forums/d540201/bases-donnees/db2/
> validation-xml-db2-v9-5-a/ <https://www.developpez.net/forums/d540201/
> bases-donnees/db2/validation-xml-db2-v9-5-a/>

Interesting. In DB2 it looks indeed more like a schema composition.
Perhaps something to consider once the current approach is ready.

Best, Jim

---

From: Pavel Stehule <[email-masked]>
Date: Wed, 1 Apr 2026 10:10:56 +0200

> Perhaps something to consider once the current approach is ready.

It should be considered from the beginning - it means that the relational
identifier is not unique.  It can complicate upgrades. And it can
complicate possible ports from db2.

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 first
step - this can be just a function too.

Theoretically there can be different access - we can introduce a generic
XMLVALIDATE command, that can call some callback. This callback can be
implemented in an extension. One extension can XML storage identified by
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.

XML is a little bit outdated - but the proposed infrastructure can be used
for any documents, so it can theoretically supports json, jsonb too, and
this can helps with accepting XMLVALIDATE to core. I expect something like
XMLVALIDATE will be JSON standard in a few years.

Regards

Pavel

---

From: Jim Jones <[email-masked]>
Date: Wed, 1 Apr 2026 16:39:56 +0200

> 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 XML.

> relation identifier, another can implement some shared storage on the
> disc outside the database etc. So the organization of the patch can be
> different 
> 
> 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?

Best, Jim

---

From: Pavel Stehule <[email-masked]>
Date: Wed, 1 Apr 2026 18:57:24 +0200

> How would XMLVALIDATE without this contrib extension look like?

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

Pavel

---

From: Marcos Magueta <[email-masked]>
Date: Thu, 2 Apr 2026 15:22:32 -0300

Hey Jim and Pavel, thanks for demonstrating interest.

> XML is a little bit outdated - but the proposed infrastructure can be
used for any documents, so it can theoretically supports json, jsonb too
[...]. I expect something like XMLVALIDATE will be JSON standard in a few
years.

That doesn't sound like a bad idea to me. But I suspect I would need to
almost completely revamp the implementation in the patch so far, so I would
like to confirm a few things before committing to anything on that front.

I am still unsure how the permissions would be managed properly with the
API approach. It seems to me we could rely on the ACL like before, but I
sense there's something more arcane around it when it comes to the
extension.

I didn't realize, but DB2 actually gives you decomposition over an xml
hierarchy into tables, which is an insanely valuable feature. I wonder how
we could go with that here using the current catalog approach.

Is there anything else that might be troublesome with changing approaches?

Regards, Marcos.

---

From: Pavel Stehule <[email-masked]>
Date: Thu, 2 Apr 2026 20:57:41 +0200

Hi

> like to confirm a few things before committing to anything on that front.

It is usual when you design a feature that is not fully described by
standard :-/. And then it is good to start primary from part (command),
that is well described by standard.

> sense there's something more arcane around it when it comes to the

There are two different things - 1. possibility to registrate xml schema -
you need just to CREATE right for related pg_namespace, 2. possibility to
use xml schema - and you need to USAGE right - and this can be checked
inside extension. Probably you cannot use all ACL related macros, and maybe
you have to design some function instead of GRANT and REVOKE.  Maybe some
form of RLS can be used. When you separate storage of XML schemas to an
extension, then you can implement just some minimalistic implementation
(just what is necessary for regress tests) - and some more complex storage
of XML schema can be designed (developed) outside the main branch.
Hypothetical storage from contrib can be enhanced step by step.

Regards

Pavel