Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] DROP TABLE inside a transaction block

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "Ross J(dot) Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
Date: 2000-03-08 23:24:35
Message-ID: 200003082324.SAA07123@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> 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.

> As a first crack, I decided to use the oid for the filename, just because
> it simplified the chamges to the Macro, and there was already an oidout()
> builtin that'd do the palloc for me ;-)
> 
> <some time latter...>
> 
> Well, ... it is, as they say, a Small Matter of Programming. I now know
> a lot more about the bootstrap process, and the relcache, I can tell you!
> 
> 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?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-03-08 23:51:37
Subject: Re: [HACKERS] alter_table.sql
Previous:From: Ross J. ReedstromDate: 2000-03-08 21:19:43
Subject: Re: [HACKERS] DROP TABLE inside a transaction block

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group