From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Stephen Frost <sfrost@snowman.net>,
 Andres Freund <andres@anarazel.de>,
        PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Multivariate MCV stats can leak data to unprivileged users
In-reply-to: 
 <CAEZATCWdjDpuDkA8xnGzDAAmDekVONj2ZegqdAkjiQE4honh2w@mail.gmail.com>
References: <20190518190042.2y33h4toxk4fxv5t@development>
 <568.1558208711@sss.pgh.pa.us> <20190518232812.qpnjmydlx3uzzsj7@development>
 <20866.1558223060@sss.pgh.pa.us> <20190518234841.GE6197@tamriel.snowman.net>
 <CAEZATCUcoAKrn-1NFkDN7md-wt6CQev0JXa+Tv31T9Jjkxgx5Q@mail.gmail.com>
 <23229.1558275148@sss.pgh.pa.us> <23772.1558276123@sss.pgh.pa.us>
 <20190519173845.tgf7ku3vigwgndn5@development> <2509.1558289694@sss.pgh.pa.us>
 <20190519224459.7dsdnv5gsfmnm4em@development>
 <CAEZATCWdjDpuDkA8xnGzDAAmDekVONj2ZegqdAkjiQE4honh2w@mail.gmail.com>
Comments: In-reply-to Dean Rasheed <dean.a.rasheed@gmail.com>
	message dated "Mon, 20 May 2019 08:33:49 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23580.1558359144.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 20 May 2019 09:32:24 -0400
Message-ID: <23581.1558359144@sss.pgh.pa.us>
Precedence: bulk

Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> On Sun, 19 May 2019 at 23:45, Tomas Vondra <tomas.vondra@2ndquadrant.com=
> wrote:
>> Oh, right. It still has the disadvantage that it obfuscates the actual
>> data stored in the pg_stats_ext_data (or whatever would it be called),
>> so e.g. functions would have to do additional checks to make sure it
>> actually is the right statistic type. For example pg_mcv_list_items()
>> could not rely on receiving pg_mcv_list values, as per the signature,
>> but would have to check the value.

> Yes. In fact, since the user-accessible view would want to expose
> datatypes specific to the stats kinds rather than bytea or cstring
> values, we would need SQL-callable conversion functions for each kind:

It seems like people are willfully misunderstanding my suggestion.
You'd only need *one* conversion function, which would look at the
embedded ID field and then emit the appropriate text representation.
I don't see a reason why we'd have the separate pg_ndistinct etc. types
any more at all.

> Also this model presupposes that all future stats kinds are most
> conveniently represented in a single column, but maybe that won't be
> the case. It's conceivable that a future stats kind would benefit from
> splitting its data across multiple columns.

Hm, that's possible I suppose, but it seems a little far-fetched.
You could equally well argue that pg_ndistinct etc. should have been
broken down into smaller types, but we didn't.

> Yes, I think it is an EAV model. I think EAV models do have their
> place, but I think that's largely where adding new columns is a common
> operation and involves adding little to no extra code. I don't think
> either of those is true for extended stats. What we've seen over the
> last couple of years is that adding each new stats kind is a large
> undertaking, involving lots of new code. That alone is going to limit
> just how many ever get added, and compared to that effort, adding new
> columns to the catalog is small fry.

I can't argue with that --- the make-work is just a small part of the
total.  But it's still make-work.

Anyway, it was just a suggestion, and if people don't like it that's
fine.  But I don't want it to be rejected on the basis of false
arguments.

			regards, tom lane