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

Re: [HACKERS] pgaccess - where to store the own data

From: Joe Conway <mail(at)joeconway(dot)com>
To: "Matthew T(dot) OConnor" <matthew(at)zeut(dot)net>
Cc: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>,Iavor Raytchev <iavor(dot)raytchev(at)verysmall(dot)org>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>,pgsql-interfaces <pgsql-interfaces(at)postgresql(dot)org>
Subject: Re: [HACKERS] pgaccess - where to store the own data
Date: 2002-08-30 18:12:28
Message-ID: 3D6FB58C.4010501@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-interfaces
Matthew T. OConnor wrote:
> One thought is to use a completely separate database, but also allow it
> to be stored in the current database if the user wants it too.  This
> also solves the case of a user that can't create a new database for his
> admin tool (permissions etc...).  Also, it might be cleaner now that we
> have schemea support to create one pgadmin, or pgaccess schemea in the
> database, that handled all the others.
> 

As someone else mentioned (I think), even using a separate schema is not 
always an acceptable option. If you are using a "packaged" application 
(whether commercial or open source), you usually don't want *any* 
changes to the vendor provided database. Particularly with commercial 
software, that can mean loss of, or problems with, technical support, or 
problems when upgrading.

Joe


In response to

Responses

pgsql-hackers by date

Next:From: Matthew T. OConnorDate: 2002-08-30 18:43:38
Subject: Re: [HACKERS] pgaccess - where to store the own data
Previous:From: Matthew T. OConnorDate: 2002-08-30 17:59:22
Subject: Re: [HACKERS] pgaccess - where to store the own data

pgsql-interfaces by date

Next:From: Matthew T. OConnorDate: 2002-08-30 18:43:38
Subject: Re: [HACKERS] pgaccess - where to store the own data
Previous:From: Matthew T. OConnorDate: 2002-08-30 17:59:22
Subject: Re: [HACKERS] pgaccess - where to store the own data

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