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 12:25:58
Message-ID: 4.2.0.58.20011002134754.00a754d0@pop.freesurf.fr (view raw or flat)
Thread:
Lists: pgadmin-hackers
>That said, if you look at the new revision control code, that may provide
>some of the answers (note that it's not all in CVS yet as I'm working on it
>at the moment).

Yes, I noticed you were working on revision control code. Revision control
is a great tool to perform upgrades. I doubt this is a reliable tool for 
rebuilding.

> > 'safe' means dependencies shall not be based on OIDs (if an object is
> > dropped, something is broken).
> > The problem with pg_dump is that it is a backup tool. What about:
> > 1) multi-user access -> we have to reload all dependant
> > objects before
> > compiling to be sure to have the latest stage.
> > 2) if one function does not compile, all dependant objects are broken.
>
>Yes, but in the example I gave, there really is no way to dump/reload (or
>recompile) the objects involved, and it's not an unreasonable scenario to
>get into. I use pg_dump as a reference, because if anything can reverse
>engineer the database correctly it will be that, and essentially that's what
>we are also trying to do.

I do not agree. The one and only way to solve all circular/dependency/PosgreSQL
questions is to read/write information in development tables.

I would swear that even Oracle is not modifying code directly in the 
database schema.
Oracle has got the same dependency problems. i.e. Code is stored in 
separate tables.

> > There have been many discussion about this on pg-hackers.
> > There is no answer to date unless there is real 1) schema and
> > 2) a real
> > depency table.
> > I think we should better go for storing all schema objects in
> > development
> > tables.
> >
> > PostgreSQL and pgAdmin II are professional tools. We cannot
> > take the risk
> > of loosing code when editing server-side objects. My company
> > framework is
> > entirely based on PostgreSQL.and pg/PLSQL. I think it is too
> > risky to go
> > for 'interpreted' solutions. What if I loose code and
> > something is broken?
>
>Then you'll need to completely rewrite pgSchema to work that way (which I'm
>not about to do). For months pgSchema has been developed in an interpretive
>way (which you were well aware of) - I'm not about to throw all those months
>of work down the drain now. I think it is a little late to be saying that
>this is not the way it should work.

We have been doing it for a long time in pgAdmin I.
This is the way developers work when writing queries in text documents.

-> Object.CodeRepository = 'production' or 'development'.
-> Object.Move (fromRepository, TargetRepository) will move code and/or 
compile it (like in pgAdmin I).

Objects shall be Table, View, Function, Trigger, etc...
pgSchema does not need much modification to handle 'production'.

> > The way that most PL/pgSQL developers handle this problem is
> > that they
> > write functions, views and triggers in a single text file
> > with DROP/CREATE
> > stuff. This works for less than 10 objects. Everyone stores
> > source code in
> > a separate place. pgAdmin I solution is interesting because it stores
> > source code in the database itself. This is not a new
> > concept. If we try to
> > mix source/compiled code, we are going in a wrong direction.
>
>If pgAdmin II stored objects as source code then it would still need to
>interpret object design by parsing SQL queries back into values and options.
>This is significantly more difficult than interpreting the data from the
>system catalogs.

Not necessarily. If people want to access development tables directly, they 
can do it.
For example, if phpPgAdmin writes in development tables, code will still 
compile.

No need to parse SQL queries when using Object.Move (from-> to) ilke in 
pgAdmin I.

>The way it works presently is the most straight forward in my opinion. The
>SQL reverse engineering can be tested using the Publishing Wizard to ensure
>it's working correctly. An audit trail can be generated from the Revision
>Control log.

I agree this is the most straight forward, but does it suit professional needs?

As for me, I still stick to pgAdmin I CVS version because my whole business 
process is based on PL/pgSQL.
I only trust dependency queries because they are real, whereas a revision 
log is only based on user input.

/Later, Jean-Michel




pgadmin-hackers by date

Next:From: Dave PageDate: 2001-10-02 13:02:10
Subject: Re: Table modification
Previous:From: Dave PageDate: 2001-10-02 11:27:48
Subject: Re: Table modification

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