On Mon, Aug 20, 2012 at 9:37 AM, salah jubeh <s_jubeh@xxxxxxxxx> wrote: > Hello Andreas, > > Thanks for the reply, The example I have posted is very simple and you are > right it is very similar to select max (id) from table_that_does_not_exist; > But there are more here, for example imagine I have something like > > CREATE VIEW a4 as select .... from a3(), .... ; > > In my opinion, this might leads to many problems such as > > 1. A lot of garbage in the database including functions refers to non > existing objects and views defined over these functions. > 2. This might also lead to some logical errors; especially, if you have a > view defined over such functions and used in external applications. > 3. You will get also a broken dependency graph, in the above example it is > obvious that a4 depends on a3 which depends on a2. If that bothers you, organize views and functions into scripts so that you can rebuild the entire suite at will. In practice, I find the problem of tables that functions depend on either A. disappearing or B. structurally changing so that the fundamental behavior of the function is broken to be a fairly rare problem. It's much more common to have to add fields, change types, etc. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
