> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > But seriously, let me give some background. I used Ingres, that used
> > the VMS file system, but used strange sequential AAAF324 numbers for
> > tables. When someone deleted a table, or we were looking at what tables
> > were using disk space, it was impossible to find the Ingres table names
> > that went with the file. There was a system table that showed it, but
> > it was poorly documented, and if you deleted the table, there was no way
> > to look on the tape to find out which file to restore.
>
> Fair enough, but it seems to me that the answer is to expend some effort
> on system admin support tools. We could do a lot in that line with less
> effort than trying to make a fundamentally mismatched filesystem
> representation do what we need.
That was my point --- that in doing this change, we are taking on more
TODO items, that may detract from our main TODO items. I am also
concerned that the filename/tablename mapping is supported by so many
Unix toolks like ls, lsof/fstat, and tar, that we could be in for
needing to support tons of utilities to enable administrators to do what
they can so easily do now.
Even gdb shows us the filename/tablename in backtraces. We are never
going to be able to reproduce that. I guess I didn't want to bit off
that much work until we had a _convincing_ need. I guess I don't
consider table schema commands inside transactions and such to be as big
an items as the utility features we will need to build.
-- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
