Re: [HACKERS] pgaccess - where to store the own data
От | Dave Page |
---|---|
Тема | Re: [HACKERS] pgaccess - where to store the own data |
Дата | |
Msg-id | 03AF4E498C591348A42FC93DEA9661B88447@mail.vale-housing.co.uk обсуждение исходный текст |
Список | 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 по дате отправления: