Re: RE: [PATCHES] relation filename patch - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: RE: [PATCHES] relation filename patch
Date
Msg-id Pine.LNX.4.21.0005020034140.389-100000@localhost.localdomain
Whole thread Raw
In response to Re: RE: [PATCHES] relation filename patch  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: RE: [PATCHES] relation filename patch  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian writes:

> > Hmm. Further perusal leads me to believe that this override is a
> > standards extension,

> I am quite surprised people don't like that feature, or at least one
> person doesn't.

FWIW, I always considered that behaviour kind of suspicious. I don't think
it's a big problem in practice and could be useful in certain situations,
but personally I would have chosen not to do it this way.

> If someone else creates a table, it should not prevent me from
> creating a temporary table of the same name.

The proper solution to this is that "somebody" should not be allowed to
create tables wildly. Until we can properly do that it's not worth arguing
this out.

> Our code even masks a real table created in the same session.  Once
> the temp table is dropped, the real table becomes visible again.  See
> the regression tests for an example of this.

The real problem here is that there's no way of finding out whether you
just dropped the temporary table or the "real" one or whether a table is
temporary at all. Sure you can perhaps look into pg_class but tell that to
users.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Proposal for fixing intra-query memory leaks
Next
From: Peter Eisentraut
Date:
Subject: Re: shmem_seq may be a bad idea