Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gljJT-0004e0-Qp for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Jan 2019 23:49:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gljJS-0001Fk-Gm for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Jan 2019 23:49:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gljJR-0001C8-T0 for pgsql-hackers@lists.postgresql.org; Mon, 21 Jan 2019 23:49:06 +0000 Received: from bay.acenet.us ([173.230.252.50]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gljJL-0001Ta-6N for pgsql-hackers@postgresql.org; Mon, 21 Jan 2019 23:49:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=anastigmatix.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=L66weVZsLDoEtJFNEOddvRAkQVM1hwofzIx/OcygYwM=; b=jhwdRTXx+YaodpXr9a0vPxqtYO t1R1DDdNvYFpyvDyjW7ccGu1J5LuefBBfA8fFBn0yRUWBHvmAtimUP98BH/80L+PGAvmOoo0V3uAH BynXYjysBx8yF1l4w1DRh9limIi2JQ7WkVjAbxRdwx9mbhLi5PTbTV9+RkjBIrDIdGjx9SWeauIgc zVGicvLO9qes/t2MnrNkNNuQhHMCRznXPJuFnuBbnSRIZvEoSG8tioTDkcLtTJ//mKMt1NbFlj6Tu iWpvOqWRgC0i83kUP5ELdJkft0zUzFPB7kiSBBtZA7L92GgrrQJf6uaEPP5hYTu/vVyRACdv2zzoN 5iThUjeg==; Received: from [192.182.57.242] (port=51567) by bay.acenet.us with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gljJG-005qrq-CR; Mon, 21 Jan 2019 18:48:56 -0500 Subject: Re: PostgreSQL vs SQL/XML Standards To: Pavel Stehule References: <45C74339-3531-46BD-A595-37183C6730A1@winand.at> <5C283168.8060001@anastigmatix.net> <5C291741.9060506@anastigmatix.net> <5C297BB7.9070509@anastigmatix.net> <5C3A7A90.3070207@anastigmatix.net> <5C3BE8CE.8010606@anastigmatix.net> Cc: Markus Winand , Alvaro Herrera , Tom Lane , PostgreSQL Hackers From: Chapman Flack X-Enigmail-Draft-Status: N1110 Message-ID: <5C465A65.4030305@anastigmatix.net> Date: Mon, 21 Jan 2019 18:48:53 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-95.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bay.acenet.us X-AntiAbuse: Original Domain - postgresql.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - anastigmatix.net X-Get-Message-Sender-Via: bay.acenet.us: authenticated_id: chap@anastigmatix.net X-Authenticated-Sender: bay.acenet.us: chap@anastigmatix.net X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, In two places in the XMLTABLE implementation (XmlTableFetchRow, iterating through a nodeset returned by the row_expression, and XmlTableGetValue, going through a nodeset returned by the column_expression), the iteration proceeds in index order through xpathobj->nodesetval->nodeTab. The same happens in the older xml_xpathobjtoxmlarray, producing the array result of the xpath() function. In one finds this unsettling comment: xmlNodePtr *nodeTab; /* array of nodes in no particular order */ So far, no matter what oddball XPath expressions I think up, nodeTab does seem to end up in document order. It would be comforting to document that, but the comment suggests it might not be guaranteed. Are you aware of any statement I might have missed in the libxml docs, where they commit to XPath evaluation returning a nodeset where nodeTab has a predictable order? If there is a statement to that effect somewhere, it might be worth citing in a comment in xml.c. Regards, -Chap Here is a fairly oddball query, generating an XML document with about 3k names in descending order, partitioning those elements into subsets having the same second character of the name, and unioning those back together. You'd sort of expect that to produce a result nodeTab in goofy order if anything could, but no, the results seem verifiably in descending order every time, suggesting the result nodeTab is indeed being put in document order before the XPath evaluator returns. If only they would document that. WITH nodeset_order_check(name, prev_name) AS ( SELECT x, lag(x) OVER (ROWS BETWEEN 1 PRECEDING AND CURRENT ROW) FROM (SELECT string_agg(DISTINCT 'x/n[substring(.,2,1) = "' || substring(proname from 2 for 1) || '"]', '|') FROM pg_proc) AS rowx(rowx), (SELECT XMLELEMENT(NAME x, XMLAGG(XMLELEMENT(NAME n, proname) ORDER BY proname DESC)) FROM pg_proc) AS src(src), XMLTABLE(rowx PASSING src COLUMNS x text PATH '.') ) SELECT every(prev_name >= name IS NOT FALSE) FROM nodeset_order_check; every ------- t (1 row)