Re: Fix for RENAME - Mailing list pgsql-hackers

From Ross J. Reedstrom
Subject Re: Fix for RENAME
Date
Msg-id 20000614123654.A28941@rice.edu
Whole thread Raw
List pgsql-hackers
Bah, while editing myself out of the To: list, I botched the mailing lists
address. Here it is, for everyone else.

Ross
----- Forwarded message from "Ross J. Reedstrom" <reedstrm@rice.edu> -----

On Sun, Jun 11, 2000 at 11:14:06PM -0400, Bruce Momjian wrote:
> Seems Vadim's new storage manager for 7.2 would be the way to go.
> 
> I think he is going to have everything in one file.
> 

Might I remind everyone that that current code is actually buggy on
NT: since the NTFS is case-insensitive/case-preserving, two tables
"fred" and "Fred" attempt to create the same file to store into.

Hiroshi had a version of my patch without the silly messing with the
relcache, that passed all the regression tests. Perhaps we should put
that in as an NT bug fix, while we wait for bigger and better things?
I have noticed a lot more activity on the mailing lists mentioning
looking at the NT port.

The patch would need to be tweaked a little: ALTER TABLE RENAME becomes
less intrusive (a mere update of relname in pg_class) and completely
under MVCC and transaction control. VACUUM may need touching to find
renamed tables and fix their physical table name then, since it's already
got the locks needed, if we want to maintain consistency of the mostly
human readable filename <-> tablename relation. It could also be fixed
up by a dump/restore, since the physical filename is generated at table
creation time.

Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005

----- End forwarded message -----


pgsql-hackers by date:

Previous
From: "G. Anthony Reina"
Date:
Subject: Re: 7.0.2 cuts off attribute name
Next
From: Tom Lane
Date:
Subject: Re: 7.0.2 cuts off attribute name