Alvaro Herrera <alvhe...@alvh.no-ip.org> writes:
> Tom Lane wrote:
>> I propose that we should just treat extended stats objects like other
>> generic database objects --- which, in practice, means "dump if the
>> containing schema is getting dumped". We don't exclude views or matviews
>> on the basis of whether their underlying tables are going to be dumped,
>> so why should stats objects operate differently from those?
> I claim that views and matviews are indeed separate objects rather than
> sub-objects belonging to a table; but a stats object is, in some way,
> just part of the table(s) definition(s), so the analogy doesn't hold
> necessarily. In particular the decision to dump the stats object should
> be connected to the table(s) rather than the stat object as standing
> alone.
Meh. The thing that is going to make this painful is when we allow
extensions to contain stats objects, something which doesn't seem to be
allowed today (at least, ALTER EXTENSION ADD STATISTICS doesn't work)
but which is surely a rather bad oversight. Consider two cases for an
extension E containing a table T:
* There is a stats object S on T, and S is also a member of E.
* There is a stats object S on T, and S is NOT a member of E
(perhaps somebody made it after the fact).
I argue that if you try to tie S's dumpability strictly to T's, you are
going to break one or the other of these cases, either treating S as if
it were a member of E when you shouldn't or vice versa. Getting the
binary-upgrade case right will make it even more complicated.
(And I haven't even mentioned, say, stats objects on two tables belonging
to different extensions.)
I think we've made our choice and it's that stats objects are independent
objects. Trying to preserve some part of the they're-just-attributes-
of-a-table view is going to create more problems than it solves.
regards, tom lane
