On Mon, Aug 07, 2006 at 03:57:05PM +0200, Pavel Stehule wrote: > >>> Are you saying that the package would effectively *be* a schema from > >the > >>> outside. That is, if I have package "foo" then I can't also have a > >schema > >>> "foo"? > > > >> Yes, because I don't need duplicity in function's names. > > > >What if the package needs some tables associated with it? I think you > >need to think harder about the relationship of packages and schemas. > >I don't necessarily object to merging the concepts like this, but > >the implications look a bit messy at first sight. > > > > regards, tom lane > > What is problem? I can attach table or sequence. What can be problem is > visibility of nesteded objects (if can be different than functions). My > proposal is only concept, and I my first goal is find way for secure > storing session's variables and shared native functions, like my sample. I > didn't think about others objecst and it's maybe error. Or maybe I was > wrong in "package is similar to schema". I wonted say so relation between > function and package is very similar to relation between functions and > schema.
Having the relationship be similar is fine... actually implimenting packages as some special kind of schema sounds like a really bad idea. IMHO, packages should themselves be first-level objects that reside under schemas. Of course that raises some interesting questions about the visibility of the functions inside a package, which is why IIRC the last time this was brought up one of the ideas was to extend schemas so that they could contain other schemas. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
