On Wed, Oct 20, 2010 at 10:28 AM, Tom Lane <t...@sss.pgh.pa.us> 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"? > > 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.
If we're looking to have any sort of "out of catalog" documentation of table storage format, what about just having a new relation fork that just "appends" each and every change made to the table formats, including ones rolled back, etc. Make this relation fork append only, and dump a completely new set of metadata to it each and every ALTER TABLE. This fork would never need to be read by PG, so a relation fork might even be too much. All you really need is a file you can tie to a relation, and blindly append "data" to on create/alter statements. Sure, it will have more information than *needed*, but I can't see it ever growing too big, and people doing forensics rarely complain about having *too much* information available. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
