Tom Lane wrote: >"Stephen R. van den Berg" <s...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
