Re: Table modification

>Yes. So you use Revision Controls Rollback option (planned, but not yet
>implemented) to undelete the object if it wasn't supposed to be dropped,
>otherwise it doesn't matter because you obviously don't want to publish it
>anyway.

No, source code should never be 'rolled back'.
We have to distinguish source (source code) from target (compiled code).

In case of problem, we roll back target, not source.

> > When several developers are working on the same database at
> > the same time,
> > you cannot guarantee consistency at PostgreSQL level.
> > Developer1 will be working in function1, while developer2
> > will be working
> > no function2 based on function1. Developer circular dependency. Boom!
>
>That is indeed the case, especially when working on a development table. If
>working on a real (but staging not production) database, then the PostgreSQL
>backend will prevent the circular dependency occuring in most cases.

No, it will not prevent it, because in many cases unresolved dependencies
are necessary and needed.
Especially when starting a project. You write that functionA is based on
functionB, and functionB does not exist.
It is normal, this is the development process. Someone else might work on
functionB the day after.

> > When an object is broken, with your system, you have to
> > retrieve source
> > code from revision logs.
> > I don't know if we can speak of ACID rules, but ... this is not a
> > consistent and atomic choice.
>
>If you or I break code in CVS (or M$ Visual Sourcesafe), then we rollback
>using a log. The fact that my system stores the SQL required to re-create
>the object is neither here nor there, it's just the easiest way or
>representing *any* object in a standard way.

CVS cannot be compared to a programming language but to a backup system.

What we call compilation is a process that starts from source (even if
source code is 'ljkgksdjgsdhglsgh')
and finishes with an executable (workable or not). The most important thing
is too preserver source code,
even in case of power failure and therefore:
- store source code in separate tables (because PostgreSQL screws up source
code with OIDs and custom modifications),
- use transactions to preserver ACID rules.

>I did consider storing copies of each attribute of each object of each type,
>however the work involved in keeping that upgradeable through versions of
>PostgreSQL would be huge. That's why the PostgreSQL upgrade procedure is
>Dump/Reload rather than pg_upgrade or similar (I believe this was tried
>once).
>
>There are 2 key points here for my system to work:
>
>1) The SQL generation must be correct. In reality (once past testing), most
>errors already appear to occur in an obvious way - the SQL syntax is
>normally screwed because of a a double quote _in_ an object name, or there's
>a missing space before a little used qualifier...

This is a huge problem.

>2) You _must_ have suitable procedures in place for publishing. i.e. all
>developers commit and logout and you refresh pgSchema before publishing
>(actually, I think I'll make pgSchema do that).

This is workable in a small team, not in a mixed pgAdmin / phppgAdmin world.

> > >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?!
> >
> > Yes my friend. Indeed, we are discussing about the (future)
> > schema features
> > of PostgreSQL.
> > We need more input on PostgreSQL core team schema and
> > dependency projects
> > ... or start our own project.
>
>Yes, it would be good to know where they are going. If there will be a
>pg_dependencies in 7.3 for example, it might be worth holding off for that
>on some tasks...

I too.

I will be helping you this time. As you know, my business depends on
PostgreSQL which has better UNICODE support in 7.2.
Our problem comes from PostgreSQL code style, between 'interpreted' and
'compiled' type.

Later/JMP