Re: WIP - xmlvalidate implementation from TODO list

Hi Marcos

On 05.01.26 18:49, Marcos Magueta wrote:
> 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?


Perhaps we need to first agree on some foundational aspects such as
design and syntax before going deeper into the code.

== return type ==

Your proposal returns a boolean, but the SQL/XML standard specifies
otherwise. In 6.21 <XML validate>:

"General Rule 8)
The result of <XML validate> is R."

where R is constructed as an XQuery sequence of nodes:

"General Rule 7)
Let R be an XQuery sequence enumerated by Rⱼ, 1 ≤ j ≤ N."

This may sound surprising at first glance, but it enables useful
patterns such as:

INSERT INTO t (c)
VALUES (XMLVALIDATE(x ACCORDING TO XMLSCHEMA s));

SELECT XMLSERIALIZE(
  XMLVALIDATE(x ACCORDING TO XMLSCHEMA s)
  AS text
);

In this model, validation failure is signaled via an error condition,
not by returning false.

== registered XML schemas ==

AFAICT the standard does not mandate any particular syntax for
registering XML schemas, so we are not required to implement REGISTER
XMLSCHEMA. Also, registered XML schemas must also be manageable objects,
which should be reflected in the proposed syntax. For example:

CREATE XMLSCHEMA foo AS '... XSD text ...';
CREATE XMLSCHEMA foo FROM file;

DROP XMLSCHEMA foo;

ALTER XMLSCHEMA foo RENAME TO bar;
ALTER XMLSCHEMA foo OWNER TO u;
ALTER XMLSCHEMA foo ADD '... new value ...';

and so on...

== permissions ==

Schema registration and usage should be privilege-controlled, for
example via dedicated roles:

GRANT pg_read_xmlschemas TO u;
GRANT pg_write_xmlschemas TO u;
...

After we have the XML schema management aspects figured out, we can move
on to XMLVALIDATE itself.

These are just my opinions. Let's also hear what the other reviewers
have to say before you start working on a v2.

Best, Jim