Josh Berkus wrote: > Tom, > > > This is exactly the sort of argumentation that got the last proposal > > shot down ;-). I see no reason that you can't do the namespacing and > > security as well or better using the existing (and more standard) schema > > feature. If there's something there that's not covered, what is it? > > a) When you have 1000's of procedures, it becomes very useful to have more > than one level of namespacing. This is not an exaggeration; one project I > looked at who decided not to convert from Oracle to PostgreSQL had over > 100,000 procedures and functions. Lack of packages was their main reason > for not switching. Schemas provide only *one* level of namespacing, unless > we want to "improve" on the SQL standard and allow nested schemas. > > b) Schemas do not provide us with any way of limiting the scope of functions > and persistent variables. With packages, you would want: > 1. functions which can only be called internally to the package > 2. variables which are only visible inside the package > 3. functions which can only be called as part of the package (thus > utilizing > the initialization and internal variables) and not on their own.
What if we defined functions to look in their own schemas for functions they call, then use the search_path, rather than using the search path first? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
