Thread: oid2name and relfilenode
Now that we are changing relfilenode in 7.3, I think we need to rename oid2name to relfilenode2name, and perhaps move it into the main tree. TODO item added: Rename oid2name to relfilenode2name and install by default -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: > Now that we are changing relfilenode in 7.3, I think we need to rename > oid2name to relfilenode2name, and perhaps move it into the main tree. > > TODO item added: > > Rename oid2name to relfilenode2name and install by default > Actually, to be accurate, I think databases are stored based on their oid and tables/indexes are stored based on their relfilenode. That is pretty confusing. Do we still do the renaming? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: > > Bruce Momjian wrote: > > Now that we are changing relfilenode in 7.3, I think we need to rename > > oid2name to relfilenode2name, and perhaps move it into the main tree. > > > > TODO item added: > > > > Rename oid2name to relfilenode2name and install by default Should it be renamed to pg_<something> for namespace consistency? :-) Regards and best wishes, Justin Clift > Actually, to be accurate, I think databases are stored based on their > oid and tables/indexes are stored based on their relfilenode. That is > pretty confusing. Do we still do the renaming? > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Justin Clift wrote: > Bruce Momjian wrote: > > > > Bruce Momjian wrote: > > > Now that we are changing relfilenode in 7.3, I think we need to rename > > > oid2name to relfilenode2name, and perhaps move it into the main tree. > > > > > > TODO item added: > > > > > > Rename oid2name to relfilenode2name and install by default > > Should it be renamed to pg_<something> for namespace consistency? Good question. We usually add the pg_ for stuff that could be confusing, like pg_dump or pg_restore. For things like vacuumdb and dropdb, we don't. We probably should have pg_ on createuser, but historically we haven't. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian writes: > > Rename oid2name to relfilenode2name and install by default > > > > Actually, to be accurate, I think databases are stored based on their > oid and tables/indexes are stored based on their relfilenode. That is > pretty confusing. Do we still do the renaming? I don't think we should do either of these. Instead of giving people tools to dig around in the internals, let's give them tools to get the information they really want. Not sure what that is though. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > > Rename oid2name to relfilenode2name and install by default > > > > > > > Actually, to be accurate, I think databases are stored based on their > > oid and tables/indexes are stored based on their relfilenode. That is > > pretty confusing. Do we still do the renaming? > > I don't think we should do either of these. Instead of giving people > tools to dig around in the internals, let's give them tools to get the > information they really want. Not sure what that is though. That's the problem. People sometimes need to access those files from the file system level. There are just too many variations of why they need that I don't think there is any way to anticipate them. If someone comes up with a better idea, I am all ears, but seeing as nothing better has appeared since it was first written, I think we need to move forward. I will add these items to the TODO list, unless someone else votes. I think they are too important to have in /contrib (and we moved pg_resetxlog/pg_controldata from /contrib in 7.3) and I think relfilenode is better than OID so people start using that rather than OID for filename mapping. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I will add these items to the TODO list, unless someone else votes.
I was not thrilled with the idea of moving oid2name out of contrib
either, but kept silent to see if someone else would complain first ...
Basically I think that oid2name is a hacker's tool and not something
users or DBAs really want as-is --- which I guess is another way of
stating Peter's gripe that what it produces is not what the users want
to know. The actual useful guts of it are nothing more thanSELECT oid, datname FROM pg_database;SELECT relfilenode,
relnameFROM pg_class;
which does not seem significant enough to justify the packaging and
documentation overhead of having another command-line tool.
The only actual use-case I've seen for it so far is as a vehicle for
computing actual database sizes on-disk; which would be better served
by a tool that did the whole job. What other uses do people have for
oid2name?
regards, tom lane
OK, removed from TODO. I figured it was as useful as pg_controldata but can see what you say that those give information that you can't get any other way, while oid2name info can be gotten another way. You can look at the oid2name README for examples of its usage. --------------------------------------------------------------------------- Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I will add these items to the TODO list, unless someone else votes. > > I was not thrilled with the idea of moving oid2name out of contrib > either, but kept silent to see if someone else would complain first ... > > Basically I think that oid2name is a hacker's tool and not something > users or DBAs really want as-is --- which I guess is another way of > stating Peter's gripe that what it produces is not what the users want > to know. The actual useful guts of it are nothing more than > SELECT oid, datname FROM pg_database; > SELECT relfilenode, relname FROM pg_class; > which does not seem significant enough to justify the packaging and > documentation overhead of having another command-line tool. > > The only actual use-case I've seen for it so far is as a vehicle for > computing actual database sizes on-disk; which would be better served > by a tool that did the whole job. What other uses do people have for > oid2name? > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073