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 1glFc5-0003GU-Kr for pgsql-hackers@arkaria.postgresql.org; Sun, 20 Jan 2019 16:06:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1glFc2-0002PE-D6 for pgsql-hackers@arkaria.postgresql.org; Sun, 20 Jan 2019 16:06:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1glFc1-0002Ot-N4 for pgsql-hackers@lists.postgresql.org; Sun, 20 Jan 2019 16:06:18 +0000 Received: from bay.acenet.us ([173.230.252.50]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1glFby-0004Qd-Tj for pgsql-hackers@lists.postgresql.org; Sun, 20 Jan 2019 16:06:16 +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=0ZOzD/FXUItJaE6mBsB6C++IWAUC7Cr7++nZQWbME/k=; b=tMKFUFDqA+I5T8jRYy/e5P8vvf tDfSSRaUFmBEgS0V1zYz3Mo1viJYrbIaxvVD7niyKo0xlejC/AqHak47UuBpzyla++6sYuAvdPz5e LnIoUcWfQApqzpQPkD4FaN0I2pe8/yJ6AYd/TkyBlPrsd1EtEPDDJ52vxLszrIOMBaiwUTcSAyS9G P5FrC6JbYkap0a2qgR6lPD1fx7HH5q2+d/Zs4mrcmwbSr6UAHJWIhiOKATt5mxmox1AHM86YX0JCJ rKSwyp670BtMzs1bpWQnEL/TXBlE9GOt88YYREGsKMAq8lOQoLecD2WcwrGt/vur0oc73nkmnsssL DKEhZYqg==; Received: from [192.182.57.242] (port=50253) by bay.acenet.us with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1glFbt-0076hx-Sv; Sun, 20 Jan 2019 11:06:13 -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> <5C43FAEB.2070000@anastigmatix.net> <5C4401BE.4080606@anastigmatix.net> Cc: PostgreSQL Hackers From: Chapman Flack X-Enigmail-Draft-Status: N1110 Message-ID: <5C449C71.7060903@anastigmatix.net> Date: Sun, 20 Jan 2019 11:06:09 -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=utf-8 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 - lists.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, On 01/20/19 00:26, Pavel Stehule wrote: >>> column expressions are evaluated once per row, but XPath expression is >>> compiled per row too, if I remember well. >> >> I looked for evidence of that in the code, but did not find it; the >> compilation appears to happen in XmlTableSetColumnFilter, which is >> called from tfuncInitialize. > > it is called per input row. I could be misunderstanding what you mean by 'input row' here. If I write a simple xmltable query where the row_expression produces six rows: SELECT * FROM xmltable('pg_am/row' PASSING table_to_xml('pg_am', true, false, '') COLUMNS amname text PATH 'amname'); six rows are produced, though a breakpoint set on XmlTableSetColumnFilter fires only once, from tfuncInitialize at the start of xmltable's execution. By contrast, in the regression test example with PATH ''||lower(_path)||'c', four rows are produced and the breakpoint fires four times. However ... that isn't because one call to xmltable is producing four rows and recomputing the column_expression each time. It's because that xmltable is the RHS of a LATERAL, and the LHS of the LATERAL is producing four tuples with different values of columns the RHS depends on, so the RHS (xmltable) is being called four different times, producing one row each time, still with XmlTableSetColumnFilter being called only during initialization. > sure - using any expression in PATH clause should to demonstrate this > functionality. Well, there seem to be two distinct features touched on in the docs: 1. The column_expression is allowed to be an expression, not restricted to a string literal as it is in the standard (and Oracle). 2. Not only is it an expression, but it's an expression whose evaluation is deferred and can happen more than once in the same xmltable call. The example in the regression tests certainly demonstrates (1). Without (1), it would be a syntax error. I think the same example would produce the same output even with feature (2) absent. It's LATERAL doing the magic there. So I am doubtful that it demonstrates (2). I put some effort last night into trying to even construct any query that would demonstrate (2), and I came up short, but that could be my lack of imagination. (Somewhere in that effort I happened to notice that xmltable doesn't seem to be parsed successfully inside a ROWS FROM (...) construct, which might be another issue for another time....) So, if you have a way to build a query that demonstrates (2), my aha! moment might then arrive. Regards, -Chap