Re: Table modification - Mailing list pgadmin-hackers

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr]
> Sent: 02 October 2001 11:35
> To: pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] Table modification
>
>
>
> >As I said, that's how pg_dump does it afaict. The only case where it
> >(and
> >pg_dump) fails that I've found so far is illustrated with
>
> Again, I am still asking myself wether PostgreSQL schema
> objects should be
> considered as 'compiled' or 'interpreted' code.
> - If it is 'compiled' code, then source code should be stored
> in separate
> tables and compiled on the run (like in any compiled language).
> - On the converse, if it is 'interpreted' code, source code
> shall be read
> directly from the database and be 'safe'.

The second option sounds correct. Many people won't want the advanced
functions, and we need to be able to pick up changes from other tools like
psql.

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

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

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

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

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.

Regards, Dave.