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 1gdn78-00068m-Jy for pgsql-hackers@arkaria.postgresql.org; Mon, 31 Dec 2018 02:15:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gdn77-0006ir-1t for pgsql-hackers@arkaria.postgresql.org; Mon, 31 Dec 2018 02:15:33 +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 1gdn76-0006ig-FB for pgsql-hackers@lists.postgresql.org; Mon, 31 Dec 2018 02:15:32 +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 1gdn6y-0007vc-KN for pgsql-hackers@postgresql.org; Mon, 31 Dec 2018 02:15:31 +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=yqrBaTzDE7j2EZnMZUEOVe+9UcsanOijJ3TvquDMmVI=; b=OPP3eMBToKk3T5iMXb6Rek7se5 RdmWOS8jcOr7LLcH63mUdOh7MBvE5SmLuDSl9wuI0J25IKfnZWvMWeWyOBUrrn3RT7R97g9MNjB0p e68n5aDDC7Ter6vmAR+2n7nSLzCScsTlrQ3opyfXae88Zgfal1sCScHkyJHMBebe4cdEzjAHkx3Ap uu9ffRXy4xVNO/QdwK4zqRnSAl2oD2q0D9fBtxMz1FMdkQcz21nnzJiTwlc4ZT73OQVA+WxrQZ+Uw BtzkxAKl7DKCoTXU52oIdKL5UrIZA+fMK3CO2EJWVFWH6UCxkNPuRKjFs4MJ/fMx6lT+6xQyYydsL rHmBSg7Q==; Received: from [192.182.57.242] (port=54096) by bay.acenet.us with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gdn6u-001Dfy-4R; Sun, 30 Dec 2018 21:15:21 -0500 Subject: Re: PostgreSQL vs SQL/XML Standards To: Pavel Stehule References: <20181025194720.ylmw64xqlnjr5wja@alvherre.pgsql> <45C74339-3531-46BD-A595-37183C6730A1@winand.at> <5C283168.8060001@anastigmatix.net> <5C291741.9060506@anastigmatix.net> Cc: Markus Winand , Alvaro Herrera , Tom Lane , PostgreSQL Hackers From: Chapman Flack X-Enigmail-Draft-Status: N1110 Message-ID: <5C297BB7.9070509@anastigmatix.net> Date: Sun, 30 Dec 2018 21:15:19 -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: 8bit 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 On 12/30/18 15:18, Pavel Stehule wrote: > ne 30. 12. 2018 v 20:06 odesílatel Chapman Flack > napsal: >> How difficult would it be to make the grammar constructs that currently >> accept "BY REF" (only as noise and ignore it) accept and ignore both BY REF >> and BY VALUE? > > This is difficult question - a implementation is probably very easy, but it > is hard to accept to possible break compatibility due syntactic sugar. > > This is not probably related to just XPath/XQuery question - but it is > related to different design of XML datatype (based on PostgreSQL TOAST) > against ANSI/SQL (Oracle - clob). > > So this is complicated topic and my opinion is better to don't touch it > because we can't to fix it, change it - and I am not sure so ANSI/SQL is > significantly better than PostgreSQL implementation. I am not sure I understand your point. It appears that Oracle (18c), just like PostgreSQL, really only supports BY VALUE semantics. Here is an Oracle fiddle that shows it: https://dbfiddle.uk/?rdbms=oracle_18&fiddle=0cb353da0d94c6d5c2659222a1e419fd When the same element is passed via two parameters, an 'is' test (node identity equality) of the two parameters returns false, indicating that Oracle has used BY VALUE semantics, not BY REF. Oracle uses BY VALUE when BY VALUE is explicitly requested, and also when no passing method is specified (i.e., BY VALUE is the default). Oracle also uses BY VALUE when BY REF is explicitly requested, which seems rather rude, but that must be the behavior PostgreSQL is imitating with the choice to accept and ignore BY REF. But the PostgreSQL situation is a little more strange. PG uses BY VALUE semantics as the default when no passing method is specified. PG also uses BY VALUE semantics when BY REF is explicitly requested, which is rude, just like Oracle. But why should an explicit specification of BY VALUE (which is, after all, the semantics we're going to use anyway!) produce this? ERROR: syntax error at or near "value" To me, that doesn't seem like least astonishment. I am not seeing what would be complicated about removing that astonishment by simply allowing the grammar productions to also consume BY VALUE and ignore it. -Chap