Tom Lane wrote:
>"Stephen R. van den Berg" <srb@cuci.nl> writes:
>> It's just that matching table and file, and subsequently figuring out
>> some missing columns which may have been added/removed later,
>> can be rather timeconsuming and could be made a lot easier (not necessarily
>> perfect) if that information would have been present in the first page of
>> a file.
>So you've already moved the goalposts from what was claimed in your
>prior message. If the data is not maintained (with 100% reliability)
>during ALTER TABLE, how are you going to do something like "figure out
>missing columns"?
Most alter table operations are well thought through and rarely undone
(at least not on production databases). This means that most tables
can be restored.
>I can see the potential usefulness of a self-documenting table storage
>format, but this proposal isn't that; it's just an unreliable kluge.
Restoring tables/databases from table storage only is, by definition,
an unreliable kludge. I'm not opposed to making the definition storage
more robust, but, since the records in the table already have lost their
relation to the pg_clog records, and therefore it *already* is uncertain
which records were deleted and/or have the wrong number of columns, it
seems to be a needless waste of time and energy to provide more reliable
information about the column structure.
I know for a fact that those who have lost data in such a way, and are
faced with the option to have this "unreliable kludgy information"
available now, or wait for a few years/months until a reliable solution
is present; they would (in every single case) opt for the former and
get at least some (if not all) of their data back in a shorter amount
of time.
--
Stephen.
Life is that brief interlude between nothingness and eternity.