Re: pg_rawdump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_rawdump
Date
Msg-id 26073.1287584929@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_rawdump  ("Stephen R. van den Berg" <srb@cuci.nl>)
Responses Re: pg_rawdump  ("Stephen R. van den Berg" <srb@cuci.nl>)
Re: pg_rawdump  (Aidan Van Dyk <aidan@highrise.ca>)
List pgsql-hackers
"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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Kenneth Marshall
Date:
Subject: Re: PostgreSQL and HugePage
Next
From: Tatsuo Ishii
Date:
Subject: Re: How to reliably detect if it's a promoting standby