Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gB588-0005hX-1U for pgsql-docs@arkaria.postgresql.org; Fri, 12 Oct 2018 21:37:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gB583-0004Ry-JR for pgsql-docs@arkaria.postgresql.org; Fri, 12 Oct 2018 21:37:51 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gB583-0004Rp-7c for pgsql-docs@lists.postgresql.org; Fri, 12 Oct 2018 21:37:51 +0000 Received: from mail-qt1-x829.google.com ([2607:f8b0:4864:20::829]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gB580-0005ZR-0R for pgsql-docs@lists.postgresql.org; Fri, 12 Oct 2018 21:37:49 +0000 Received: by mail-qt1-x829.google.com with SMTP id l9-v6so15421757qtf.5 for ; Fri, 12 Oct 2018 14:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zCqPhNPtIFEmGNbVzVaOgKK8MwNeFteWG1BD52MILuc=; b=dXYBrQ13wt1PpuCeXA0pjrdYmjF5G+h9y8pS0jFKrR4a46GLNOwGcAAOPl5UigNa97 wQO8ongaRiIwmCIrbFQDtm416Ldr3VvcCbA/WSps0TLqnqbbj+Jl4Hxd64ZAp9R+tA9p jBwKFyh9Yq2XFto3ZYiXzdURmGGfpVLhmjWxXfFp4ur/WWP1D61CcIFEth8pKD82e5UL JCGXwjUkuLv61QpQjZeQsrY58UefirIE9w8oF2BlHxbcug5s8FiqoqSukY03FrImbCp9 7kyTdiksB6cEX8AVux56kJNeRksRPzILWiGbbj6lxVufjSrrtDwVaTV95hq+eAtZxPmr DilQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zCqPhNPtIFEmGNbVzVaOgKK8MwNeFteWG1BD52MILuc=; b=B6qzs/90tpihovuQJXsqNUcxHx3t50XiaBjyEB3tx7XHf41yhhOls5tC3F0fIAJTs5 1jxpm6TMgn6fAaXsE2VRaOjIoqgtu52P3qyCjsiPqGG+QZeo6NM0mRqlYK71jWWl9mqb m+FAVeOoS93E291uiHi12OjfQsRmp04Fy678+ZpHRc9EAy3uCzK32EafQ0K3MlpMjsst 9/iARTMMxn1HuFeWwZmzILckg9qVckmXi+m2VeWw9vlIfGTcVk1D7mN47NKa5ou1za1B jZoTucNBk8icrd3gXkhri7xoRIrDh+HRRAVd49QO5MjzWBNT31rWm9MfUO3LYOz27SP+ 7XVQ== X-Gm-Message-State: ABuFfogr0QJV4Qx1oBS+p0sXcycMYkuPAvriLPBGIUHM4oy0j5zf1VfA bodHxzcf6RRQ790LGD3smr5zCm3qsOiYd8o7q2Y= X-Google-Smtp-Source: ACcGV60bgYVDRPkRxzxCdD1IqzyEw6x2dO+QaqKdOOEy7zPkg+xgn+d7vKbGsyDIbnvKdQx7eJfjU5qPSEY5u+N3PVk= X-Received: by 2002:aed:3f4c:: with SMTP id q12-v6mr7524139qtf.282.1539380266934; Fri, 12 Oct 2018 14:37:46 -0700 (PDT) MIME-Version: 1.0 References: <153701242703.22334.1476830122267077397@wrigleys.postgresql.org> <20181011210934.GG7807@momjian.us> <5831541539340923@iva8-3af116a85b74.qloud-c.yandex.net> <20181012150433.GA12966@momjian.us> In-Reply-To: <20181012150433.GA12966@momjian.us> From: "David G. Johnston" Date: Fri, 12 Oct 2018 14:37:33 -0700 Message-ID: Subject: Re: Ambiguous usage of 'any' in explanation To: Bruce Momjian Cc: KES , pgsql-docs@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000fc254905780ee56e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000fc254905780ee56e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 12, 2018 at 8:04 AM Bruce Momjian wrote: > Sorry, but I don't like this wording. The problem is that the > comparison has two row sets --- the left-hand side, and the right-hand > side. Huh...the left hand side must be a non-set scalar or row constructor. Each row on the left-hand side is compared with the row set on > the right. I also don't like people thinking about the result of ANY > since it is really ANY that is being used. > Then there is some more rewording to be done since: "The result of ANY is =E2=80=9Ctrue=E2=80=9D if any true result is obtained." (v10; 9.22.4) Maybe: The result of ANY is =E2=80=9Ctrue=E2=80=9D if the comparison returns true = for any subquery row; otherwise the result is =E2=80=9Cfalse=E2=80=9D (or NULL if any of the= comparisons result in unknown) David J. --000000000000fc254905780ee56e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 12, 2018 at 8:04 AM Bruce Mom= jian <bruce@momjian.us> wrote= :
Sorry, but I don't like this wording.=C2=A0 The pro= blem is that the
comparison has two row sets --- the left-hand side, and the right-hand
side.

Huh...the left hand side must be a= non-set scalar or row constructor.

=C2=A0 Each row on the left-hand side = is compared with the row set on
the right.=C2=A0 I also don't like people thinking about the result of = ANY
since it is really <comparison> ANY that is being used.

Then there is some more rewording to be done since: &q= uot;The result of ANY is =E2=80=9Ctrue=E2=80=9D if any true result is obtai= ned." (v10; 9.22.4)

Maybe:

The re= sult of ANY is =E2=80=9Ctrue=E2=80=9D if the comparison returns true for an= y subquery row; otherwise the result is =E2=80=9Cfalse=E2=80=9D (or NULL if= any of the comparisons result in unknown)

<= div class=3D"gmail_default">Dav= id J.

--000000000000fc254905780ee56e--