public inbox for [email protected]
help / color / mirror / Atom feedFrom: Marcos Magueta <[email protected]>
To: Jim Jones <[email protected]>
Cc: Andrey Borodin <[email protected]>
Cc: Kirill Reshke <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: WIP - xmlvalidate implementation from TODO list
Date: Tue, 6 Jan 2026 15:03:15 -0300
Message-ID: <CAN3aFCcXwS7BrU1gHRUEBH3G59EVf_7LUhLeEWqW2Sc9Vk5k-A@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
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>
<[email protected]>
<[email protected]>
<[email protected]>
<CAN3aFCfdGp6TGTQNOVO1im1u2vO_E2jnTGVV2xhea7eNY7GtuQ@mail.gmail.com>
<[email protected]>
Hey Jim!
On 06.01.26, Jim Jones <[email protected]> wrote:
> The result of <XML validate> is R.
That was an oversight on my behalf, I had a hard time understanding the
standard, but now the validation of DOCUMENT and CONTENT being accepted
makes more sense.
The current patch has some issues.
> xmloption is document_or_content. But xmlvalidate_text_schema() always
validates as a document.
As Andrey noticed, we should indeed support both a document and content.
Which entails into an iterative validation (for each node provided) on
content mode, so I should likely add the xmloption back. The fact it worked
with the example I created was actually luck.
Also, I am not sure if some variables used inside of the PG_TRY are memory
safe -- notice that none right now is set to volatile, despite being
accessed in different parts of the block; other functions in xml.c do
handle such correctly it seems (like xml_parse).
About the syntax proposal by Jim, I have no problems with complying to it.
It does increase considerably the scope from what I originally intended,
but that's the price to have something actually nice.
I can think of several useful extensions we could consider in a further
implementation:
Schema Dependencies/Imports
CREATE XMLSCHEMA base AS '...';
CREATE XMLSCHEMA extended
IMPORTS base
AS '...';
Schema Versioning
CREATE XMLSCHEMA patient VERSION '1.0' AS '...';
CREATE XMLSCHEMA patient VERSION '2.0' AS '...';
XMLVALIDATE(doc ACCORDING TO XMLSCHEMA patient VERSION '2.0')
Custom Error Messages
CREATE XMLSCHEMA patient
AS '...'
ERROR MESSAGE 'Patient record does not match schema v2.0';
Schema inference from samples (if the lib supports it, that is)
CREATE XMLSCHEMA patient
INFER FROM (SELECT data FROM patient_samples);
And much more, but perhaps that's already too ambitious for a first version.
I'll wait for the others to ring their bells.
Regards, Magueta.
view thread (10+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: WIP - xmlvalidate implementation from TODO list
In-Reply-To: <CAN3aFCcXwS7BrU1gHRUEBH3G59EVf_7LUhLeEWqW2Sc9Vk5k-A@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox