Skip site navigation (1) Skip section navigation (2)

Re: Table modification

From: Jean-Michel POURE <jm(dot)poure(at)freesurf(dot)fr>
To: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Table modification
Date: 2001-10-02 17:37:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
>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

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


pgadmin-hackers by date

Next:From: Dave PageDate: 2001-10-02 19:13:52
Subject: Re: Table modification
Previous:From: Jean-Michel POUREDate: 2001-10-02 16:51:37
Subject: Re: Column lenght

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group