Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ahwlO-0006iP-4f for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Mar 2016 10:08:42 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1ahwlN-0002tJ-Io for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Mar 2016 10:08:41 +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.84_2) (envelope-from ) id 1ahwlM-0002t5-L7 for pgsql-hackers@postgresql.org; Mon, 21 Mar 2016 10:08:40 +0000 Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1ahwlJ-0001Fh-6W for pgsql-hackers@postgresql.org; Mon, 21 Mar 2016 10:08:39 +0000 Received: by mail-wm0-x22b.google.com with SMTP id p65so115128379wmp.0 for ; Mon, 21 Mar 2016 03:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=jfTiOVib70G0iNS/FUxM95Rkcd/vZYVi9zI2Yi9zl3k=; b=JP2Ao0OoOOCJBbcb3P6wIHlVycks3Qmm/BhQs6Uk0AJkOXKEZb/vAy3Cg10k+a43f0 ufkLncSLqrhuGKVlK4F6C3aBl1IY6Ekpi4AFx3BU7B8M8trigq6oH/hPPLA6BNWUMEcd cTlFCLDMnhEsJ6VV/7njmyZiwcYksiI93aYzRhqlORF+WfoMH5CLCShurXyxFhNxqJnC tQjvbElsvOVRQjUSrMqT+Ko9URdK3/HfXj21V/w2Utom69zoBgVrJWQv1ZxbzqtwvqPO HJT61cftzywglgngmkuvpa1YCGbcHX8P0zUYB7870chnbSlfhTrDW4bmDDWIExjObuDe do1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jfTiOVib70G0iNS/FUxM95Rkcd/vZYVi9zI2Yi9zl3k=; b=W63snP2BOIh9x13pGp3Ph3HMit372NPWMlBPFdCJvv5kmyiWzZ4I5GqAG1qCytNP2V TdS+Abmnhj+J9hk0V54UhtPXqIl0P0Ju9Mty0KOLlt7m0vM8V8+wXbrSFf7McEIL/WOy HxAner13SLLVRp6xnqGlO1kCAoDS+wVxbAo5lxGdZM87pjt3Et50/9O5XvVPL9Sw70C8 aLtLZZa4QsuZOC+A1sYzrNQv47YxwU6uX5Qv+xyFF1u0TjbXc1L/5I1XSuR01AB3koYn RMNXb9m1PzF0wJCYyOg1tf4+Nl1xgx09KX2xKc8tu6N7jol+aRTuOEtUyA9xGPLQOqpB xnoA== X-Gm-Message-State: AD7BkJIaVKg7vHCRjgDNh0HUy+kSLAHb9h4/HrNwShNd9mrHRO5FDChhjdWjTc9VwQM898HtM9CtdQEquIHRyyrZEUM+agvC9KTBtM1i7kbDldPVe/Gll0uyPGQ58+Ah5YLyw3jW2ffV2vKtooDUVSPKl9/QsQF1HQpOMO/GSsr1eT27xDO0h31bnolw1irSwB8LU4Ei6voT X-Received: by 10.28.34.67 with SMTP id i64mr12336073wmi.85.1458554915539; Mon, 21 Mar 2016 03:08:35 -0700 (PDT) Received: from [10.137.2.17] (ip-78-45-216-26.net.upcbroadband.cz. [78.45.216.26]) by smtp.gmail.com with ESMTPSA id lh1sm24494092wjb.20.2016.03.21.03.08.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 03:08:34 -0700 (PDT) Subject: Re: multivariate statistics v14 To: Robert Haas , Alvaro Herrera References: <1bc2bd16-8e33-9e22-cdb1-9ddc38fedc4c@2ndquadrant.com> <20160321033440.GA350186@alvherre.pgsql> Cc: Tatsuo Ishii , Kyotaro HORIGUCHI , Jeff Janes , "pgsql-hackers@postgresql.org" From: Tomas Vondra Message-ID: Date: Mon, 21 Mar 2016 11:08:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Thunderbird/46.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Hi, On 03/21/2016 10:34 AM, Robert Haas wrote: > On Sun, Mar 20, 2016 at 11:34 PM, Alvaro Herrera > wrote: >> ObjectProperty[] contains a comment that the ACL is "same as relation", >> but is that still correct, given that now stats may be related to more >> than one relation? Do we even know what the rules for ACLs on >> cross-relation stats are? One very simple way to get around this is to >> dictate that all the rels must have the same owner. > > That's not really all that simple - you'd have to forbid changing > the owner of a relation involved in multi-rel statistics, but that's > horrible. Presumably at the very least you'd then have to find some > way of allowing the owner of everything in the group to be changed > at the same time, but that's a whole new innovation. I think this is > a very messy line of attack. I agree. I don't think we should / need to impose such additional restrictions (e.g. same owner for all tables). I think for using the statistics (to compute estimates for a query), it should be enough that the user can access all the tables it's built on. Which happens somehow implicitly, and currently it's trivial as each statistics is built on a single table. I don't have a clear idea what should we do in the future with multiple tables (e.g. when the statistics is built on 3 tables, the query is on 2 of them and the user does not have access to the remaining one). But maybe we need to support ACLs because of ALTER STATISTICS? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers