Re: proposal for PL packages for 8.3.

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, dev(at)archonet(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: proposal for PL packages for 8.3.
Date: 2006-08-07 19:27:14
Message-ID: 20060807192714.GD40481@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-08-07 19:42:31 Re: CSStorm occurred again by postgreSQL8.2
Previous Message Stefan Kaltenbrunner 2006-08-07 19:25:27 Re: buildfarm - make check failures for leveret on 8.0