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 1vcTPb-00755o-08 for pgsql-hackers@arkaria.postgresql.org; Sun, 04 Jan 2026 19:05:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vcTPZ-00Fsar-1f for pgsql-hackers@arkaria.postgresql.org; Sun, 04 Jan 2026 19:05:10 +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 1vcTPZ-00Fsaj-0X for pgsql-hackers@lists.postgresql.org; Sun, 04 Jan 2026 19:05:10 +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 1vcTPX-004Ak5-1i for pgsql-hackers@lists.postgresql.org; Sun, 04 Jan 2026 19:05:08 +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=1767553507; x=1799089507; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Lp/7QM7lKolPrJmkKDev4PiC+GZhDjMC0jMy2vw2tzc=; b=Si7AO9sO5yRdDOPC7Wr3Sb7YmiHeMfw6nkK8fY/WQl78R9pRk5pY8AiS twoLoT03jmCYRFfZrLkIeHIHCxHXy+4C7rSXxKrrCbtW5BidARm709OCk Oemsrl6nwW1Fny6KmJ07EH4UE2401FFxEyFzlSD1quDZNkgTqXEBwY2/4 ZS0j32A6Lf+eHPZ/3jQUpog90/jURT4VGJXr34sJG6kABI7iM+MiiNyao QL2ingdnVINAVQRRTjvcvPkk/NU93Go1p5K5ytvTRR0y9sNC8c2sjxvrH psFDCBDz6V8bfC+9L9PwbTViAwXgz8n1izV5CKvoDQrNwbEDcE2GASpKL g==; X-CSE-ConnectionGUID: +dMfsJahRguuVCcyKRGUMQ== X-CSE-MsgGUID: DGAWOQHPQzKcZpI7l9lu2g== X-IronPort-AV: E=Sophos;i="6.21,202,1763420400"; d="scan'208";a="379817182" Received: from secmail.uni-muenster.de ([128.176.118.4]) by UDCM-RELAY2.UNI-MUENSTER.DE with ESMTP; 04 Jan 2026 20:05:03 +0100 Received: from [192.168.178.27] (dynamic-080-171-091-249.80.171.pool.telefonica.de [80.171.91.249]) by SECMAIL.UNI-MUENSTER.DE (Postfix) with ESMTPSA id AFBD920ADF00; Sun, 4 Jan 2026 20:05:02 +0100 (CET) Message-ID: <70c72cb1-a39f-41b3-bfe3-e32ee7fda9c4@uni-muenster.de> Date: Sun, 4 Jan 2026 20:05:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: WIP - xmlvalidate implementation from TODO list To: Andrey Borodin , Marcos Magueta Cc: Kirill Reshke , PostgreSQL Hackers References: <89DE974B-F318-4D0A-A60B-51EDE84054E2@gmail.com> <9A074422-2308-4BD0-9FFA-0B6D70989935@yandex-team.ru> Content-Language: de-DE, en-GB From: Jim Jones In-Reply-To: <9A074422-2308-4BD0-9FFA-0B6D70989935@yandex-team.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi! On 04/01/2026 10:46, Andrey Borodin wrote: > So you need to update src/test/regress/expected/xml_1.out for systems without libxml. +1 There is also a xml_2.out. I don't really remember why it exists, but in your case copying the changes from xml.out will most likely do the trick. I am wondering whether passing the XML schema in every query is really the right approach here. My main concern is that making the schema fully user-controlled at execution time could lead to unwanted CPU or memory usage -- not to mention the usability aspect of it. A catalog-level schema registration mechanism would IMHO be a better fit, and it's also supported by the SQL/XML standard: "11.5 Format ... ::= ID ... Syntax Rules 1) If is specified, then the shall identify a registered XML schema RXS... " DB2 handles this similarly via REGISTER XMLSCHEMA.[1] Thanks for working on this! Best, Jim [1] https://www.ibm.com/docs/en/db2/11.5.x?topic=commands-register-xmlschema