At 12:03 PM 5/6/01 -0400, 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 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.
>Nobody particularly likes numeric filenames, but there really isn't any
>other workable answer.
OK. Found one of the discussions at:
http://postgresql.readysetnet.com/mhonarc/pgsql-hackers/2000-03/threads.html
#00088
Conclusion calling stuff oid.relname doesn't really work. Sorry to have
brought it up again.
Another idea that's probably more messy than it's worth:
Main object still called <oid> with a symlink called <oid.originalrelname>.
DB really just uses <oid>.
Rename= adds symlink called <oid.newrelname>, doesn't remove symlinks
(symlinks more for show!).
Committed drop table does what 7.1 does with the main oid entry.
Vacuum cleans up the symlinks leaving just a single valid one or zaps all
if the table has been dropped.
For windows create empty files named oid.relname instead of symlinks.
Windows will definitely like .verylongrelname extensions ;).
Kinda messy and kludgy. Throw in the performance reduction and Ick!
I probably have to think harder :), maybe there's just no good way :(.
Ah well,
Link.
