> -----Original Message-----
> From: Matthew T. OConnor [mailto:matthew(at)zeut(dot)net]
> Sent: 30 August 2002 18:59
> To: Dave Page
> Cc: Iavor Raytchev; pgsql-hackers; pgsql-interfaces
> Subject: Re: [HACKERS] pgaccess - where to store the own data
> > > What do people think about this. Is it so bad that the own
> > > data is stored in the database pgaccess works with?
> > pgAdmin II no longer uses such tables, but to get over the
> problem as
> > best I could, I added a cleanup option to pgAdmin I that
> removed all
> > server side objects in one go.
> What does pgAdmin II do instead? Or, how did you solve the problem?
pgAdmin II 1.2.0 optionally used one table for it's revision control
feature. This has been removed in the latest code 'cos I was never
totally happy with it, and no-one admitted to using it when I quizzed
The other objects (views, functions and tables) have been removed either
because pgAdmin II is far cleverer in the way it caches things than
pgAdmin I was and can get away with 2 queries instead of one or a more
complex one if required, or, because features such as monitoring of
sequence values and tables sizes were dropped in the great rewrite.
It's also worth noting, that pgAdmin and pgAccess have different aims.
Whilst pgAccess aims to provide application bulding and reporting
facilities (like Access) which naturally require a centralised data
store, pgAdmin is intended as a pure Admin tool aiming to fully support
all PostgreSQL object types.
pgsql-hackers by date
|Next:||From: Joe Conway||Date: 2002-08-30 20:18:30|
|Subject: Re: SRF memory mgmt patch (was [HACKERS] Concern about|
|Previous:||From: Gordon Runkle||Date: 2002-08-30 19:52:52|
|Subject: [7.3-devl] alter_table test|
pgsql-interfaces by date
|Next:||From: Christopher Kings-Lynne||Date: 2002-08-31 12:38:03|
|Subject: Re: [HACKERS] pgaccess - where to store the own data|
|Previous:||From: terry||Date: 2002-08-30 19:18:22|
|Subject: Re: pgaccess - where to store the own data|