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

Re: RFD: schemas and different kinds of Postgres objects

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, Fernando Nasser <fnasser(at)redhat(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RFD: schemas and different kinds of Postgres objects
Date: 2002-01-25 03:23:22
Message-ID: 200201250323.g0P3NMY22893@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> writes:
> > When configured for historical behavior would need to:
> > 1. have search path: temp, any, system
> > 2. guard against duplicate table names across all schemas (except temp schema)
> 
> This would be a *whole* lot simpler if we forgot the notion of "any"
> and made the search order look like
> 
> 	(temp, private, public, system)
> 
> where the public namespace is world-writable but the private per-user
> ones are (typically at least) not.

[ I am just reading this schema thread now.]

The above private/public idea seems like a much better than 'any'.  That
'any' thing had me quite confused and the idea thought you would have
duplicates that would only be found at runtime seems destined to random
falures.

I assume 'private' above means search in my personal schema/namespace.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  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

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-01-25 03:26:43
Subject: Re: RFD: schemas and different kinds of Postgres objects
Previous:From: Tom LaneDate: 2002-01-25 03:11:34
Subject: Re: Ready for RC2 I guess...

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