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 1w7wjh-0003nD-1j for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Apr 2026 14:40:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w7wjg-000Xlf-1F for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Apr 2026 14:40:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w7wjg-000XlW-08 for pgsql-hackers@lists.postgresql.org; Wed, 01 Apr 2026 14:40:00 +0000 Received: from udcm-wwu2.uni-muenster.de ([128.176.118.28]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w7wjd-000000001pW-3D6H for pgsql-hackers@lists.postgresql.org; Wed, 01 Apr 2026 14:40:00 +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=1775054398; x=1806590398; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=47UkhBvhdatc16SwOAgj6R/Mr0pwtB74l6Cj+RtLcNY=; b=ghoTk1b/l4K6gh0IcZgsOsEpBUuAkSyDYougCe2gRwM/MRo3LcLPpAK/ v85pm3r+xvBP5clUbN+G5RX6duT8fFlOkb6NZz2qGQeV6C8+gYl9iiV+7 lZCyN9uc+eiYwhd3PYlw8B77LojRnGb1w8pxQ83F3z3ZgRjZYYy6MfoI6 mQmSVnjYWFgsUduCiD5JA+i+nW0uqt2dFhpex5mDJy+0QW+nbwS98/VPC tCcQP59zQaImNlJKe8tM3z6yvmbS1pxVejgyQ/dnbv0QJbmOtxE5QZ58M axaPOqIKADzjWJD6pATganzxLeGyJi+X+FtiTb3dOdUnATUnYNrGFz8S9 A==; X-CSE-ConnectionGUID: GwTEwmu0TAK9AIEksOZNWg== X-CSE-MsgGUID: tSAiZKdbRhSYWJVy9TOmsw== X-IronPort-AV: E=Sophos;i="6.23,153,1770591600"; d="scan'208";a="389503102" Received: from secmail.uni-muenster.de ([128.176.118.4]) by UDCM-RELAY2.UNI-MUENSTER.DE with ESMTP; 01 Apr 2026 16:39:57 +0200 Received: from [128.176.190.180] (wwuit-jones-w.wwu.de [128.176.190.180]) by SECMAIL.UNI-MUENSTER.DE (Postfix) with ESMTPSA id 7BED220ADF00; Wed, 1 Apr 2026 16:39:56 +0200 (CEST) Message-ID: Date: Wed, 1 Apr 2026 16:39:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: WIP - xmlvalidate implementation from TODO list To: Pavel Stehule Cc: Marcos Magueta , Andrey Borodin , Kirill Reshke , PostgreSQL Hackers References: <2ba05acc-6392-42a4-b59e-61df086b2d4d@uni-muenster.de> <1d49e214-93bc-4928-945c-27e60251a6ad@uni-muenster.de> <9228b6dc-cfae-4a11-927a-209680f5507e@uni-muenster.de> <2f8ca841-0956-4e7d-8fa2-038b879c8f4d@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 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? Best, Jim