Re: [HACKERS] pgaccess - where to store the own data - Mailing list pgsql-interfaces

From Dave Page
Subject Re: [HACKERS] pgaccess - where to store the own data
Date
Msg-id 03AF4E498C591348A42FC93DEA9661B88447@mail.vale-housing.co.uk
Whole thread Raw
List pgsql-interfaces

> -----Original Message-----
> From: Matthew T. OConnor [mailto:matthew@zeut.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-interfaces by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: [HACKERS] pgaccess - where to store the own data
Next
From: rexrecio@yahoo.com (Rex Recio)
Date:
Subject: 7.2.1 failure to complie C programs