From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Multivariate MCV stats can leak data to unprivileged users |
Date: | 2019-05-19 14:28:43 |
Message-ID: | 23772.1558276123@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> I wonder ... another way we could potentially do this is
> create table pg_statistic_ext_data(
> stxoid oid, -- OID of owning pg_statistic_ext entry
> stxkind char, -- what kind of data
> stxdata bytea -- the data, in some format or other
> );
> The advantage of this way is that we'd not have to rejigger the
> catalog's rowtype every time we think of a new kind of extended
> stats. The disadvantage is that manual inspection of the contents
> of an entry would become much harder, for lack of any convenient
> output function.
No, wait, scratch that. We could fold the three existing types
pg_ndistinct, pg_dependencies, pg_mcv_list into one new type, say
"pg_stats_ext_data", where the actual storage would need to have an
ID field (so we'd waste a byte or two duplicating the externally
visible stxkind field inside stxdata). The output function for this
type is just a switch over the existing code. The big advantage of
this way compared to the current approach is that adding a new
ext-stats type requires *zero* work with adding new catalog entries.
Just add another switch case in pg_stats_ext_data_out() and you're
done.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Riou | 2019-05-19 15:36:23 | PROXY protocol support |
Previous Message | Tom Lane | 2019-05-19 14:12:28 | Re: Multivariate MCV stats can leak data to unprivileged users |