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 first > 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.
> > 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.
How would XMLVALIDATE without this contrib extension look like?
The API can be similar to PLpgSQL plugin API - and rendezvous variable
