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 10:35:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
>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'.

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

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 

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?

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.

As usual, if you find the answer I will be glad about it.

pgadmin-hackers by date

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

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