Re: [HACKERS] DROP TABLE inside a transaction block

On Wed, Mar 08, 2000 at 06:24:35PM -0500, Bruce Momjian wrote:
> > Looked like it was going to be very simple: the RelationGetRelationName
> > and RelationGetPhysicalRelationName macros encapsulate access to the
> > (relation)->rd_rel->relname structure member pretty effectively (thanks
> > to Bruce's temp. relation work, I presume)
> 
> Yes.

Well, thank you, then ;-)
> 
> > 
> > Most problems where code that used RelationGetPhysicalRelationName
> > when they it should use RelationGetRelationName. In several cases,
> > the code assumed RelationGetPhysicalRelationName handed them a
> > pointer to rd_rel->relname, which they copy into! I substituted
> > RelationGetRelationName for all these cases.
> 
> Please send in a patch on those if they need to be corrected, OK?
> 

Once I'm sure it's the Right Thing To Do, I will. That's probably
the only clean part of the ugly hack I've done so far.

I've got a complete system up, now. For some reason, the bootstrapping
in initdb doesn't create the pg_log (or pg_shadow!) relations, even
though the same step on a clean CVS tree does. Can't quite find why. So,
the non-bootstrap connections in initdb (creating all the system views)
then fail.  If I manually copy the pg_log and pg_shadow files over from
'current' to 'hacked', I can then run the code from initdb by hand,
and get a fully functional system.

I went ahead and ifdefed out the rename() in renamerel(). Low and behold,
I can rollback an ALTER TABLE RENAME, and have a concurrent session
see the right thing. The conncurent session hangs, though, because of
the exclusive lock. Based on comments in that function, I think the
lock is still needed to handle the buffer cache, which is indexed by
relname. Should probably make that indexed by PhysicalName, since they're
disk buffers, after all. Haven't touched DROP TABLE, yet though.

My real goal with all this is to now look at the parser, and see how
hard it will be to do something with schema. I think that's going to
require an other field in the relation structure, to indicate which
schema a relation belongs to, then control access based on what the
current default schema is. All the relname stuff was just so different
schema can have different tables with the same name. ;-)

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