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

AW: Big 7.1 open items

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Hiroshi Inoue'" <Inoue(at)seiren(dot)co(dot)jp>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
Subject: AW: Big 7.1 open items
Date: 2000-07-03 08:28:05
Message-ID: 219F68D65015D011A8E000006F8590C605BA59B0@sdexcsrv1.f000.d0188.sd.spardat.at (view raw or flat)
Thread:
Lists: pgsql-hackers
> > > > > In my mind the point of the "database" concept is to 
> > > provide a domain
> > > > > within which custom datatypes and functions are available.
> > > >
> > > 
> > > AFAIK few users understand it and many users have wondered
> > > why we couldn't issue cross "database" queries.
> > 
> > Imho the same issue is access to tables on another machine.
> > If we "fix" that, access to another db on the same instance is just
> > a variant of the above. 
> >
> 
> What is a difference between SCHAMA and your "database" ?
> I myself am confused about them.

"my *database*" corresponds to the current database, which is created with
"create database" in postgresql. It corresponds to the catalog concept in
SQL99.

The schema is below the database. Access to different schemas with one
connection
is mandatory. Access to different catalogs (databases) with one connection
is not mandatory,
but should imho be solved analogous to access to another catalog on a
different 
(SQL99) cluster. This would be a very nifty feature.

Andreas 

pgsql-hackers by date

Next:From: Philip WarnerDate: 2000-07-03 08:33:21
Subject: Re: AW: Modified pg_dump & new pg_restore need testing...
Previous:From: Zeugswetter Andreas SBDate: 2000-07-03 08:18:19
Subject: AW: Modified pg_dump & new pg_restore need testing...

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