From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us> |
Subject: | Re: [PROPOSAL] Backup and recovery of pg_statistic |
Date: | 2015-12-23 15:46:22 |
Message-ID: | 26804.1450885582@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru> writes:
>> That concern is exactly the reason why we never did this originally.
>> In particular, emitting raw INSERTs into pg_statistic is just plain
>> foolish; we have changed the rowtype of pg_statistic in the past and
>> are likely to do so again. At a minimum we would need such a facility
>> to be proof against addition of more statistic "slots" (more columns)
>> to pg_statistic.
> While this approach may indeed look dumb, it is intended to be used only in
> conjunction with 'binary-upgrade' option, which effectively means that the
> pg_dump-generated INSERT statement has to be compatible only with the release
> that includes this very pg_dump version. Thus, there's no need for validation.
There's still the problem that it won't work across a major version
upgrade that makes any change whatsoever to the rowtype of pg_statistic.
That's a sufficient reason to reject it.
If the amount of infrastructure required were trivial, I'd probably be
okay with just putting it in as a kluge that pg_upgrade could use for
some version transitions and not others. But your proposal seems quite
complicated, which makes me think we could solve the more general problem
for roughly comparable amounts of work.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ildus Kurbangaliev | 2015-12-23 16:10:53 | Re: Review: GiST support for UUIDs |
Previous Message | Robert Haas | 2015-12-23 15:44:39 | Re: pgbench --latency-limit option |