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 1h1PTk-0008AC-6Q for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Mar 2019 05:52:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h1PTi-0002Gy-RH for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Mar 2019 05:52:30 +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 1h1PTi-0002Gr-Jz for pgsql-hackers@lists.postgresql.org; Wed, 06 Mar 2019 05:52:30 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h1PTf-0002Hy-Qv for pgsql-hackers@lists.postgresql.org; Wed, 06 Mar 2019 05:52:30 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x265qNY7001610; Wed, 6 Mar 2019 00:52:23 -0500 From: Tom Lane To: Paul Ramsey cc: PostgreSQL Hackers Subject: Re: Allowing extensions to supply operator-/function-specific info In-reply-to: <14E63B07-1751-4CE6-9126-4D237B9C085A@cleverelephant.ca> References: <15193.1548028093@sss.pgh.pa.us> <6953.1548297558@sss.pgh.pa.us> <6044.1548524131@sss.pgh.pa.us> <19993.1548697885@sss.pgh.pa.us> <7671.1551135674@sss.pgh.pa.us> <11051.1551139751@sss.pgh.pa.us> <14747.1551219541@sss.pgh.pa.us> <91BAE1F4-7C16-4F87-849F-B01175A8D7D8@cleverelephant.ca> <17244.1551226168@sss.pgh.pa.us> <74C11775-67A7-48D2-B1E3-24C52A686F86@cleverelephant.ca> <15086.1551310830@sss.pgh.pa.us> <24277.1551320775@sss.pgh.pa.us> <26156.1551734021@sss.pgh.pa.us> <31607.1551739943@sss.pgh.pa.us> <48F6F422-4! ! ! ! F50-4DA6-A6A1-13C4AA1B9D27@cleverelephant.ca> <914.1551745379@sss.pgh.pa.us> <24446.1551828396@sss.pgh.pa.us> <25179.1551830171@sss.pgh.pa.us> <14E63B07-1751-4CE6-9126-4D237B9C085A@cleverelephant.ca> Comments: In-reply-to Paul Ramsey message dated "Tue, 05 Mar 2019 17:22:21 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1608.1551851543.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 06 Mar 2019 00:52:23 -0500 Message-ID: <1609.1551851543@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Paul Ramsey writes: >> On Mar 5, 2019, at 3:56 PM, Tom Lane wrote: >> Then you're at least missing adequate tests for the 3-arg functions... >> 3 args with the index column second will not work as this stands. > Some of the operators are indifferent to order (&&, overlaps) and other= s are not (@, within) (~, contains). Right. > The 3-arg functions fortunately all have && strategies. Hm ... that probably explains why it's okay to apply the "expand" behavior to the non-indexed argument regardless of which one that is. I imagine the official definition of those functions isn't really symmetrical about which argument the expansion applies to, though? > The types on either side of the operators are always the same (geometry = && geometry), ST_Intersects(geometry, geometry). > I could simply be getting a free pass from the simplicity of my setup? Yeah, seems so. The real reason I'm pestering you about this is that, since you're the first outside user of the support-function infrastructure, other people are likely to be looking at your code to see how to do things. So I'd like your code to not contain unnecessary dependencies on accidents like that ... regards, tom lane