Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vd4po-00Dgxl-2b for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Jan 2026 11:02:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vd4pn-007Qiz-27 for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Jan 2026 11:02:44 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vd4pn-007Qiq-0U for pgsql-hackers@lists.postgresql.org; Tue, 06 Jan 2026 11:02:44 +0000 Received: from udcm-wwu2.uni-muenster.de ([128.176.118.28]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vd4pl-004Uhp-2d for pgsql-hackers@lists.postgresql.org; Tue, 06 Jan 2026 11:02:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-muenster.de; i=@uni-muenster.de; q=dns/txt; s=uniout; t=1767697362; x=1799233362; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=daufc3hGNULlFDVh+9gCbTFx4RfyC+7EioTWLxFM5bc=; b=pD1+bnxxvPQh+XNL3/f02lPnR8b0W/zWm/KZHuEWMMAt55v/8OPsufNh G7rsjvFqAaPzL79aaLOzAguwOJlCK2B9NhDS8ahLyvGcaSt9GfC4r7HSW 5KHBpCZFDOX+DVT4Os8izXT7qjdwqLW5iFSEQgPYAjGs3GidegWrOeKFQ R5Ljze5iPsiVHBXbLx2JkP7obEhFzP7Eq8nqrEkvtw7B03uLUT+XpesGi eI+rSrFmPniOqjbjyACJCtrfKncM9j4X6XMZ6NM/GDMUlvudsJOT5WoIg CP+rkpnOWOXCcFZIV/SNWogGTYW1ZkyjwZMSL7h9FJMZrDeLZxVEfUx1Y Q==; X-CSE-ConnectionGUID: 45aCUtO+TmaARPhTWxMrRA== X-CSE-MsgGUID: 1DDcUA5kQgauNe0GSZJ40A== X-IronPort-AV: E=Sophos;i="6.21,204,1763420400"; d="scan'208";a="379999899" Received: from secmail.uni-muenster.de ([128.176.118.4]) by UDCM-RELAY2.UNI-MUENSTER.DE with ESMTP; 06 Jan 2026 12:02:38 +0100 Received: from [128.176.190.180] (wwuit-jones-w.wwu.de [128.176.190.180]) by SECMAIL.UNI-MUENSTER.DE (Postfix) with ESMTPSA id 8A2DD20ADF00; Tue, 6 Jan 2026 12:02:37 +0100 (CET) Message-ID: <68a012d3-121b-418a-913b-aa0aaf32915d@uni-muenster.de> Date: Tue, 6 Jan 2026 12:02:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: WIP - xmlvalidate implementation from TODO list To: Marcos Magueta Cc: Andrey Borodin , Kirill Reshke , PostgreSQL Hackers References: <89DE974B-F318-4D0A-A60B-51EDE84054E2@gmail.com> <9A074422-2308-4BD0-9FFA-0B6D70989935@yandex-team.ru> <70c72cb1-a39f-41b3-bfe3-e32ee7fda9c4@uni-muenster.de> Content-Language: en-US From: Jim Jones In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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 : "General Rule 8) The result of 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