On Wed, Oct 20, 2010 at 10:28 AM, Tom Lane <tgl@sss.pgh.pa.us> 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"?
>
> 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,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
