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: 03AF4E498C591348A42FC93DEA9661B88447@mail.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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.

Browse pgsql-hackers by date

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

Browse pgsql-interfaces by date

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