> In reality, very few people are going to be interested in restoring
> a table in a way that breaks referential integrity and other
> normal assumptions about what exists in the database.
This is not true. In my DBA history it would have saved me manweeks
of work if an easy and efficient restore of one single table from backup
would have been available in Informix and Oracle.
We allways had to restore most of the whole system to another machine only
to get back at some table info that would then be manually re-added
to the production system.
A restore of one table to a different/new tablename would have been
very convenient, and this is currently possible in PostgreSQL.
(create new table with same schema, then replace new table data file
with file from backup)
> The reality
> is that most people are going to engage in a little time travel
> to a past, consistent backup rather than do as you suggest.
No, this is what is done most of the time, but it is very inconvenient
to tell people that they loose all work from past days, so it is usually
done as I noted above if possible. We once had a situation where all data
was deleted from a table, but the problem was only noticed 3 weeks later.
> This is going to be more and more true as Postgres gains more and
> more acceptance in (no offense intended) the real world.
>
> >Right now, we use 'ps' with args to display backend
> information, and ls
> >-l to show disk information. We are going to lose that here.
>
> Dependence on "ls -l" is, IMO, a very weak argument.
In normal situations where everything works I agree, it is the
error situations where it really helps if you see what data is where.
debugging, lsof, Bruce already named them.
Andreas