Received: from localhost (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP id 293BF476A45
	for <pgsql-interfaces@postgresql.org>;
	Fri, 30 Aug 2002 14:49:57 -0400 (EDT)
Received: from relay01.roc.frontiernet.net (relay01.roc.frontiernet.net
	[66.133.131.34])
	by postgresql.org (Postfix) with ESMTP id 82E214769A4
	for <pgsql-interfaces@postgresql.org>;
	Fri, 30 Aug 2002 14:49:56 -0400 (EDT)
Received: (qmail 13701 invoked from network); 30 Aug 2002 18:49:56 -0000
Received: from unknown (HELO there) ([170.215.128.148])
	(envelope-sender <tg5027@citlink.net>)
	by relay01.roc.frontiernet.net (qmail-ldap-1.03) with SMTP
	for <pgsql-interfaces@postgresql.org>; 30 Aug 2002 18:49:56 -0000
Content-Type: text/plain;
  charset="iso-8859-1"
From: terry <tg5027@citlink.net>
Organization: None
To: pgsql-interfaces@postgresql.org
Subject: Re: pgaccess - where to store the own data
Date: Fri, 30 Aug 2002 15:18:22 -0400
X-Mailer: KMail [version 1.3.2]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20020830184956.82E214769A4@postgresql.org>
X-Virus-Scanned: by AMaViS new-20020517
X-Archive-Number: 200208/93
X-Sequence-Number: 3055


>>  Iavor Raytchev wrote:
>>  > Hello everybody,
>>  >
>>  > There is an open question we need broad opinion on.
>>  >
>>  > Currently pgaccess stores its own data in the database it works
>>  > with. Some people do not like that. To store it elsewhere invokes
>>  > a number of issues such as:
>>  >
>>  > - where is this somewhere
>>  > - converting form all versions to the new
>>  > - etc.
>>  >
>>  > What do people think about this. Is it so bad that the own data
>>  > is stored in the database pgaccess works with?
>>
>>  I don't particularly like it. Oracle deals with this by having a
>>  database unto itself as a management repository (Oracle Enterprise
>>  Manager, OEM, I believe). You register the database you want to
>> manage with the repository, and the metadata is kept there instead
>> of in each managed database.
>>
>>  Joe

I would agree that pgaccess's metadata should not necessarily be stored
in with <all> of the rest of the data being used by a pgaccess
application.  However, having a central repository as described above
may make it difficult to distribute an application without providing
some capabilities to distribute/manage a portion of the central
repository - which could be ugly for the developer and an end user.