Re: Table modification

>pgAdmin I *will not* work with PostgreSQL 7.2. Bear that in mind if you look
>to upgrade.

I will not upgrade to PostgreSQL 7.2 before pgAdmin I development features
are ported, one way or another, to pgAdmin II.

>Where else would the input come from if not the user?
>
>The logs are more reliable than trying to figure out what's dependent on
>what. This is true because the logfiles represent the actual chronological
>sequence of object development. Therefore, following this *must* create
>dependencies in the correct order.

I don't agree. logfiles do not always represent the actual chronological
sequence of object development.
Again any application, i.e. phpPgAdmin, should be able to write in pgAdmin
development tables.

Looking for dependencies in the source code is much more relevant and
consistent.
Then you compile code and review compilation errors.

>Another idea to consider: The Publishing Wizard. I believe this provides
>roughly the same facilities but in a much safer environment:
>
>When intending to use the publishing Wizard, you will build your PL/pgSQL
>code in a development database. This is safer than building in development
>tables because it uses the actual database to store items so you will
>instantly become aware of any problems building objects, and more
>importantly, you have no developers with hair-delete keys anywhere near your
>production systems.

No, it not safer. If you run a DROP FUNCTION query in psql, you might not
notice it before publishing.
I will never believe that storing source code in two different places
(PostgreSQL and revision logs)
is better than in one place development tables. This is a problem of
consistency.

Using development tables, anything can be organized within one transaction.
In the long run, we could also write PL/pgSQL triggers to compile code
interactively!!!

It will never be the case with revision logs.

>Once you are happy that your 'staging' database is correct, you create
>another test database, into which you publish the staging database. Further
>checking should prove that the test database is correct (if not then a
>pgAdmin bug report would be appropriate).
>
>Now that you've successfully completed a test publication of your new code,
>you can publish to your production database(s).

I agree that a publishing wizard is needed.

>By using a process like this, you:
>
>A) develop on non-production systems without risking the live or production
>systems (and therefore your or your shareholders profit).
>B) prove your database before going live.
>C) can publish to many production systems.
>
>This system has already saved one of my staff from having to re-key a 200
>row table just this week (and it's only Tuesday lunchtime now)!
>
>This is a different working methodology, but it does give the same results
>with low risk. Thoughts or comments welcomed of course...

Well, we are discussing about two different issues:
1) keeping source code in development tables better <-> retrieving source
code from logs in case of problems.
2) compilation in dependency order (=publishing, I think it is close).

We agree on 2) and disagree on 1).

Later/JMP