On Sun, May 19, 2019 at 10:28:43AM -0400, Tom Lane wrote:
>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.
>
The annoying thing is that this undoes the protections provided by special
data types generated only in internally. It's not possible to generate
e.g. pg_mcv_list values in user code (except for C code, at which points
all bets are off anyway). By abandoning this and reverting to bytea anyone
could craft a bytea and claim it's a statistic value.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services