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

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

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Matthew T(dot) OConnor" <matthew(at)zeut(dot)net>
Cc: "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 20:02:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-interfaces

> -----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 lists.

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.

Regards, Dave.

pgsql-hackers by date

Next:From: Joe ConwayDate: 2002-08-30 20:18:30
Subject: Re: SRF memory mgmt patch (was [HACKERS] Concern about
Previous:From: Gordon RunkleDate: 2002-08-30 19:52:52
Subject: [7.3-devl] alter_table test

pgsql-interfaces by date

Next:From: Christopher Kings-LynneDate: 2002-08-31 12:38:03
Subject: Re: [HACKERS] pgaccess - where to store the own data
Previous:From: terryDate: 2002-08-30 19:18:22
Subject: Re: pgaccess - where to store the own data

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