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
> >>> outside. That is, if I have package "foo" then I can't also have a
> >>> "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
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