Re: Table modification

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm(dot)poure(at)freesurf(dot)fr]
> Sent: 02 October 2001 14:47
> To: pgadmin-hackers(at)postgresql(dot)org
> Subject: Re: [pgadmin-hackers] Table modification
>
> >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.

??? Of course the system will notice! If the function has been dropped,
pgAdmin can't generate the SQL to create it on the target server!

Obviously it is possible to drop the function in psql between pgSchema
reading the database and the Wizard actually running, but you just need to
make sure your development procedures will prevent that from happening -
that's common sense though, you don't want anyone continuing development
whilst you are 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.

Precisely my argument (which is why I'm now confused). PostgreSQL itself
should be the primary repository as only it will truly validate any object
i.e. if it's invalid, PostgreSQL will through an error.

The Revision logs are not used for any purpose other than an audit trail and
providing a mechanism for rolling back changes. I'm not proposing that we
use them for anything else, I was merely pointing out that the code that
tracks the status of an objects rcs entry (i.e. whether it is up-to-date,
not in the rcs or modified since the last commit (by psql for example)) may
be of use.

> 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.

Like I say, this is not what they are intended for. I think we are arguing
at cross purposes.

> >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).

I'll disagree with that ;-)

1) I don't want to retrieve source from logs. I want to analyse the database
and generate the source from what is known to work and compile correctly.
There is no better test for an object than to build it in PostgreSQL.

2) Yes, compilation must be in dependancy order (which Publishing is). I
don't know how we could ever get over my circular dependency problem though.
That *would* require logs to figure out the sequence of queries required to
create the circular dependency in the first place. And yes, I do agree that
that is nasty...

A good heated debate does brighten up the day don't you think?!

Later, Dave.