Tom Lane wrote:
>
> Hannu Krosing <hannu@tm.ee> writes:
> > Even the IMHO hardest to solve problem
> > - RENAME - can
> > probably be done in a transaction-safe manner by doing a
> > link(oid.<newname>) in the
> > beginning and selective unlink(oid.<newname/oldname>) at commit time.
>
> Nope. Consider
>
> begin;
> rename a to b;
> rename b to a;
> end;
>
> And don't tell me you'll solve this by ignoring failures from link().
> That's a recipe for losing your data...
I guess link() failures can be safely ignored _as long as_ we check that
we have the right link after doing it. I can't see how it will lose
data.
> I would ask people who think they have a solution to please go back and
> reread the very long discussions we have had on this point in the past.
I think I have now (No way to guarantee I have read _everything_ about
it,
but I did hit about ~10 messages on oid_relname naming scheme).
the most serious objection seemed to be that we need to remember the
postgres tablename while it would be much easier to use only oids .
I guess we could hit some system limits here (running out of directory
entries or reaching the maximum number of links to a file) but at least
on
linux i was able to make >10000 links to one file with no problems.
now that i think of it I have one concern - it would require extra work
to use tablenames like "/etc/passwd" or others that use characters that
are
reserved in filenames which are ok to use in 7.1.
hannu=# create table "/etc/passwd"(
hannu(# login text,
hannu(# uid int,
hannu(# gid int
hannu(# );
CREATE
hannu=# \dt List of relations Name | Type | Owner
-------------+-------+-------/etc/passwd | table | hannu
So if people start using names like these it will not be easy to go back
;)
> Nobody particularly likes numeric filenames, but there really isn't any
> other workable answer.
At least we could put links on system relations, so it would be
easier to find them.
I guess one is not supposed to rename/drop system tables ?
---------------------
Hannu
