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 1wPTtB-000lEF-38 for pgsql-bugs@arkaria.postgresql.org; Tue, 19 May 2026 23:30:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wPTt7-005Lup-2f for pgsql-bugs@arkaria.postgresql.org; Tue, 19 May 2026 23:30:14 +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 1wPGL1-00437f-0p for pgsql-bugs@lists.postgresql.org; Tue, 19 May 2026 09:02:08 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wPGKz-00000000LDV-0uFV for pgsql-bugs@lists.postgresql.org; Tue, 19 May 2026 09:02:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=s0ECdtPZivFWy8MS8SgFiW+fYihYtWnU0H5fC8EHy+0=; b=pPn53wX0hNsgvKYauaMBu7LvRV Sh/D2Z74mmBkwDcVgM3aLVPq/PDeY/kmyRWvs8gc+jBYQEMhby44vrbQg4yLPAwC0pT6txGYNprHn CXm+48jcBcJA9f6ah0d9k8t0XHKXkF8q1TVNLWTbnDv7OgzZlnLOeRLbE3kbivBDobPlNPwcXerCQ QDEC/sqJdVa9gYGQNOi+c2o1RUuiCEcxcOc2WD9AHUZ7Vhvs/bDJOFa0kWaG7f/agJXCq8pSNLmlZ tHVP+cmcF3hwGCwXQRKKlVVTdGYL5BjDHQrSvB6e1fz26vpYSWK4h4GWSHBs+mjFC6agVZqhl5uRl z45qV7lg==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wPGKw-000uHo-2Q for pgsql-bugs@lists.postgresql.org; Tue, 19 May 2026 09:02:03 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wPGKw-001ttq-2m for pgsql-bugs@lists.postgresql.org; Tue, 19 May 2026 09:02:02 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19487: Error while executing SQL query involving XML parsing To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: i.portnov@compassplus.com Reply-To: i.portnov@compassplus.com, pgsql-bugs@lists.postgresql.org Date: Tue, 19 May 2026 09:01:10 +0000 Message-ID: <19487-367258bc497b923a@postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The following bug has been logged on the website: Bug reference: 19487 Logged by: Ilya Portnov Email address: i.portnov@compassplus.com PostgreSQL version: 18.3 Operating system: Ubuntu 24.04 LTS Description: =20 Hello. While testing our software product for compatibility with PostgreSQL 18, we found a problem which appears when executing particular query. Initial query we were executing was quite complex and involved our custom SQL functions; we tried to simplify it as far as we could, but it's still not very simple. Environment which we used to reproduce this: OS: Ubuntu 24.04 LTS Architecture: x86_64 PostgreSQL version() output: PostgreSQL 18.3 (Ubuntu 18.3-1.pgdg22.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04.3) 11.4.0, 64-bit We also tried on several different Linux distributions and PostgreSQL builds, the problem still reproduces. So, steps to reproduce are: 1. Create function: create or replace function xml_to_text(pXml xml) returns text as $$ select case when pXml is document then (xpath('/*/text()', pXml))[1] ::text else pXml::text end; $$ language sql immutable; 2. Execute query: select xml_to_text( (xpath('ns:rq/@Day', case when tbl.strcolumn !=3D '' then XMLParse(document tbl.strcolumn) when tbl.clobcolumn !=3D '' then XMLParse(DOCUMENT replace(replace(replace(replace(replace(tbl.clobcolumn, '', '?'),'', '?'),'', '?'),'', '?'), '', '?')) else XMLParse(DOCUMENT '') end, array[array['ns', 'http://example.com/schema.xsd']] ))[1] ) from ( (select '' as strcolumn, null as clobcolumn) union all (select '' as strcolumn, null as clobcolumn) ) tbl; Expected result, which is what we get on PostgreSQL 17.9: xml_to_text | -----------------------+ 2019-12-16T00:00:00.000| 2019-12-16T00:00:00.000| Actual result on PostgreSQL 18.3: SQL Error [2200M]: ERROR: could not parse XML document Detail: line 1: Start tag expected, '<' not found 2019-12-16T00:00:00.000 ^ Where: SQL function "xpath" statement 1 SQL function "xml_to_text" statement 1 It appears that all parts of problematic query are important for this problem: if I try to simplify it, for example if I try to remove one of five nested replace() calls, the problem goes away. This looks like a problem which was introduced somewhere between PostgreSQL 17 and 18. Any help in fixing it will be appreciated. Best regards, Ilya V. Portnov.