>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
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?
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.
Cheers,
Jean-Michel
