From: | Jean-Michel POURE <jm(dot)poure(at)freesurf(dot)fr> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | pgsql-general(at)postgresql(dot)org, pgsql-admin(at)postgresql(dot)org |
Subject: | ALTER / DROP information for pgAdmin2 |
Date: | 2002-02-13 09:39:35 |
Message-ID: | 200202130939.g1D9dZL02619@www1.translationforge |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-general pgsql-hackers |
Dear hackers,
Sorry to come back to ALTER /DROP object features, but I need some advice.
1) What we did in pgAdmin1
In late version of pgAdmin 1, we used to maintain two sets of objects :
- one set of production objects (queried from PostgreSQL schema) including
tables, views, triggers, etc..
- one set of development objects (which were stored in separate tables).
Every modification of objects (ex: functions, triggers, views) would apply
first in the development tables. During development, productions objects were
not modified.
At the user request, it was possible to compile the project and generate
production objects. We called this process "Rebuilding", but I prefer to say
"compiling".
Before compiling, of course, we created a dependency list of objects to
define compilation order.
The advantages of such a process were :
- to be able to store development code on a separate server.
- to have better team work with fewer bugs.
- ability to modify / drop objects (YES!!!).
As a power user, I confirm PostgreSQL cannot be used in a profesionnal
environment, with teams of developpers and heavy code (1000 tables, 500
views, 200 triggers).
And this is not a problem of "replication" as PostgreSQL can be optimized for
heavy loads ... when you have the propers development tools: pgAdmin1.
Why replicate a server when optimization itself would suffice...
2) Where we are going with pgAdmin 2
Because we are a community, we need more information to be able to get
pgAdmin2 in the right direction :
- do we need to create our own "fake" production / development modes as we
did in pgAdmin 1. This would be quite a lot of work now and an immense
deception,
- or are you going to provide us with real ALTER/DROP features. Please inform
us of the work to be done : dependency tracking, md5sum stamping of objects,
integration of patches... I know some of you are fully booked on replication.
Are others working on ALTER/DROP?
3) Need for information / user needs
In the Gnome community, projects are clearly defined and owned by major
developpers. Who is working on the ALTER /DROP project? Who can I ask for
advice as regards pgAdmin2? Could there be some clear presentation of
projects on PostgreSQL website with ownership of projects.
Also, do not hesitate to set up a pool out of the to-do-list. Results would
surprise some of you. This was just my 0.000002 cents. The overall quality of
PostgreSQL is excellent, so don't flame me for this mail.
We only need more information from hackers to make a better pgAdmin2.
Cheers,
Jean-Michel POURE
From | Date | Subject | |
---|---|---|---|
Next Message | sreedhar | 2002-02-13 11:23:33 | [ADMIN] Problem while connecting pgAdmin II v1.2 |
Previous Message | Nebojsa Pirocanac | 2002-02-13 09:35:39 | Number of connection |
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Elphick | 2002-02-13 10:14:20 | Re: First time installer !! |
Previous Message | Vaclav Kulakovsky | 2002-02-13 08:47:49 | Postgres 7.2 - Updating rows in cursor problem |
From | Date | Subject | |
---|---|---|---|
Next Message | noy | 2002-02-13 10:13:27 | Re: Permissions problem |
Previous Message | Aniket Kulkarni | 2002-02-13 09:01:10 | Information about XLogWrite |