Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gEb1Y-00026q-TZ for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Oct 2018 14:17:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gEb1W-0006M8-W9 for pgsql-hackers@arkaria.postgresql.org; Mon, 22 Oct 2018 14:17:38 +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_SHA384:256) (Exim 4.89) (envelope-from ) id 1gEb1W-0006M1-P6 for pgsql-hackers@lists.postgresql.org; Mon, 22 Oct 2018 14:17:38 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gEb1U-000381-BE for pgsql-hackers@lists.postgresql.org; Mon, 22 Oct 2018 14:17:38 +0000 Received: from pro.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w9MEHVY5000662; Mon, 22 Oct 2018 10:17:32 -0400 From: Tom Lane To: Amit Langote cc: Peter Eisentraut , PostgreSQL Hackers Subject: Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof? In-reply-to: References: <3876.1531261875@sss.pgh.pa.us> <11560.1531349520@sss.pgh.pa.us> <3ad75dc5-4ae7-087a-f2f8-b3bd92a8b2b0@2ndquadrant.com> <1029.1531578563@sss.pgh.pa.us> Comments: In-reply-to Amit Langote message dated "Mon, 22 Oct 2018 23:03:03 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83024.1540217851.1@sss.pgh.pa.us> Date: Mon, 22 Oct 2018 10:17:31 -0400 Message-ID: <83025.1540217851@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Amit Langote writes: > On Sat, Jul 14, 2018 at 11:29 PM Tom Lane wrote: >> Peter Eisentraut writes: >>> ... For >>> partitioning, we can rely on all the columns being inherited, but not >>> for plain inheritance. >> Uh, what? > But maybe for the case under question, that's irrelevant, because > we're only interested in access to inherited columns as those are the > only ones that can be accessed in queries via parent. Yeah, that's what I thought. It seems like it should be possible to base all stats access decisions off the table actually named in the query, because only columns appearing in that table could be referenced, and only that table's permissions actually get checked at runtime. I guess it's possible that a child table could have, say, an index on column X (inherited) and column Y (local) and that some aspect of costing might then be interested in the behavior of column Y, even though the query could only mention X not Y. But then we could fall back to the existing behavior. regards, tom lane