Josh Berkus wrote:
> Bruce,
>
> > > >Added to TODO:
> > > >
> > > >* Add the features of packages
> > > > o Make private objects accessable only to objects in the same
> > > > schema
> > > > o Allow current_schema.objname to access current schema objects
> > > > o Add se
Bruce,
> > >Added to TODO:
> > >
> > >* Add the features of packages
> > > o Make private objects accessable only to objects in the same
> > > schema
> > > o Allow current_schema.objname to access current schema objects
> > > o Add session variables
> > > o Allow
ssion variables
> >>o nested schemas?
> >>
> >>---
> >>
> >>Dave Held wrote:
> >>
> >>
> >>>>-Original Message-
> >>>>From:
en
Cc: Tom Lane; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Oracle Style packages on postgres
[...]
I suppose. I think we should focus on the use cases for Oracle
packages, rather than the specific functionality it provides.
What things do people need PostgreSQL to
sday, May 10, 2005 8:43 AM
> > > To: Thomas Hallgren
> > > Cc: Tom Lane; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
> > > Subject: Re: [HACKERS] Oracle Style packages on postgres
> > >
> > > [...]
> > > I suppose. I think we should foc
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 11, 2005 2:22 PM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Oracle Style packages on postgres
>
>
> "Dave
On 2005-05-11, Tom Lane <[EMAIL PROTECTED]> wrote:
> There are a number of issues that would have to be solved to make this
> actually work, but on first glance it seems like a possibly attractive
> idea.
>
> Besides, I can't wait to hear the moans from the newsysviews crew when
> the implications
On Wed, May 11, 2005 at 02:41:43PM -0700, elein wrote:
> Adding to the ambiguity is the dot notation used for
> composite columns. Don't forget the other end ignoring
> those required parens.
>
> is foo.bar.zap
> a database.schema.table
> a schema.table.column
> a table.column
On Wed, May 11, 2005 at 05:43:32PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Wed, May 11, 2005 at 05:28:22PM -0400, Tom Lane wrote:
> >> No, actually, I was wondering where the potentially N levels of schema
> >> names would appear in the output ...
>
> > My immedi
Adding to the ambiguity is the dot notation used for
composite columns. Don't forget the other end ignoring
those required parens.
is foo.bar.zap
a database.schema.table
a schema.table.column
a table.column.column
--elein
On Wed, May 11, 2005 at 03:21:42PM -0400, Tom L
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Wed, May 11, 2005 at 05:28:22PM -0400, Tom Lane wrote:
>> No, actually, I was wondering where the potentially N levels of schema
>> names would appear in the output ...
> My immediate thought is that they would be appended together in 'dot
> notation
On Wed, May 11, 2005 at 05:28:22PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Wed, May 11, 2005 at 04:49:52PM -0400, Tom Lane wrote:
> >> Besides, I can't wait to hear the moans from the newsysviews crew when
> >> the implications of this sink in ;-) ;-)
>
> > Oh no
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Wed, May 11, 2005 at 04:49:52PM -0400, Tom Lane wrote:
>> Besides, I can't wait to hear the moans from the newsysviews crew when
>> the implications of this sink in ;-) ;-)
> Oh no, not recursive function calls! :P
No, actually, I was wondering wher
On Wed, May 11, 2005 at 04:49:52PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > How is a catalog different from a schema?
>
> In the spec there's a hard-wired difference: catalogs contain schemas,
> schemas don't contain other schemas. The idea at hand here is to make
> our namespaces serv
Bruce Momjian writes:
> How is a catalog different from a schema?
In the spec there's a hard-wired difference: catalogs contain schemas,
schemas don't contain other schemas. The idea at hand here is to make
our namespaces serve both purposes. (I knew there was a good reason
not to use the word
Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> >> There are some nontrivial issues to be thought about here, like under
> >> what conditions "CREATE SCHEMA foo" ought to create a top-level schema
> >> versus creating a schema under some other schema that we are pretending
> >> is the ac
Rod Taylor <[EMAIL PROTECTED]> writes:
>> There are some nontrivial issues to be thought about here, like under
>> what conditions "CREATE SCHEMA foo" ought to create a top-level schema
>> versus creating a schema under some other schema that we are pretending
>> is the active "catalog". But it se
On Wed, 2005-05-11 at 15:41 -0400, Rod Taylor wrote:
> > There are some nontrivial issues to be thought about here, like under
> > what conditions "CREATE SCHEMA foo" ought to create a top-level schema
> > versus creating a schema under some other schema that we are pretending
> > is the active "ca
> There are some nontrivial issues to be thought about here, like under
> what conditions "CREATE SCHEMA foo" ought to create a top-level schema
> versus creating a schema under some other schema that we are pretending
> is the active "catalog". But it seems on first glance like something
> could
"Dave Held" <[EMAIL PROTECTED]> writes:
> /*
> * We check the catalog name and then ignore it.
> */
> if (!isValidNamespace(name[0]))
> {
> if (strcmp(name[0], get_database_name(MyDatabaseId)) != 0)
>
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 11, 2005 10:55 AM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Oracle Style packages on postgres
>
>
> "Dave Held" <[EMAIL PR
"Dave Held" <[EMAIL PROTECTED]> writes:
> The rule is simple: when the identifier has more than
> two parts, search for the first part among the schemas first, and then
> the catalogs.
This doesn't actually work, because there is already ambiguity as to
which level the first name is. See for inst
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 10, 2005 11:42 PM
> To: Bruce Momjian
> Cc: Dave Held; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Oracle Style packages on postgres
>
> [...]
> There's been
David Fetter wrote:
> On Tue, May 10, 2005 at 09:49:13PM -0400, Bruce Momjian wrote:
> > David Fetter wrote:
> > > On Tue, May 10, 2005 at 06:55:39PM -0400, Bruce Momjian wrote:
> > > >
> > > > OK, so it seems we need:
> > > >
> > > > o make private objects accessable only to objects in
Bruce Momjian writes:
> OK, so it seems we need:
> o make private objects accessable only to objects
> in the same schema
> o Allow current_schema.objname to access current
> schema objects
> o session variables
> o nested schemas?
There's been a lo
On Tue, May 10, 2005 at 09:49:13PM -0400, Bruce Momjian wrote:
> David Fetter wrote:
> > On Tue, May 10, 2005 at 06:55:39PM -0400, Bruce Momjian wrote:
> > >
> > > OK, so it seems we need:
> > >
> > > o make private objects accessable only to objects in the same
> > > schema
> > > o Al
David Fetter wrote:
> On Tue, May 10, 2005 at 06:55:39PM -0400, Bruce Momjian wrote:
> >
> > OK, so it seems we need:
> >
> > o make private objects accessable only to objects
> >in the same schema
> > o Allow current_schema.objname to access current
> >schema objects
>
On Tue, May 10, 2005 at 06:55:39PM -0400, Bruce Momjian wrote:
>
> OK, so it seems we need:
>
> o make private objects accessable only to objects
> in the same schema
> o Allow current_schema.objname to access current
> schema objects
> o session variables
; > Subject: Re: [HACKERS] Oracle Style packages on postgres
> >
> > [...]
> > I suppose. I think we should focus on the use cases for Oracle
> > packages, rather than the specific functionality it provides.
> > What things do people need PostgreSQL to do that it al
Dave Held wrote:
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, May 10, 2005 8:43 AM
> > To: Thomas Hallgren
> > Cc: Tom Lane; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
> > Subject: Re: [HACKER
Jim C. Nasby wrote:
I guess maybe I'm not clear on what you mean by static methods. IIRC, in
Oracle nomenclature, static means it will retain state between
invocations in the same session. Of course, functions and procedures
that don't do this are also allowed.
A STATIC prefix on a method simply
On Tue, May 10, 2005 at 08:40:16PM +0200, Thomas Hallgren wrote:
> Jim C. Nasby wrote:
>
> >I don't believe types allow for internal-only methods. I seem to recall
> >other limitations on what types could do as opposed to packages. Of
> >course, we need not restrict ourselves in such a manner.
> >
Jim C. Nasby wrote:
I don't believe types allow for internal-only methods. I seem to recall
other limitations on what types could do as opposed to packages. Of
course, we need not restrict ourselves in such a manner.
Do Oracle packages support internal only functions? If they do, then I
agree,
On Mon, May 09, 2005 at 09:56:53PM -0400, Bruce Momjian wrote:
> OK, so it seems we need:
>
> C static/private functions for schemas
> C static/private variables for schemas
>
> Are private variables implemented via the temporary per-session schema?
>
> nested schemas
>
> What
On Mon, May 09, 2005 at 11:24:45PM +0200, Thomas Hallgren wrote:
> In Oracle you can use the syntax:
>
> ..()
>
> but you can just as well use the syntax:
>
> ..()
>
> Why do you need both? If PostgreSQL is going to add new nice features
> that enables better namespace handling and global vari
On Tue, May 10, 2005 at 12:01:54PM +0300, Adrian Maier wrote:
> > Personally, I think the biggest win here would be adding package support
> > and syntax to plpgsql. Not only would it make porting from Oracle
> > easier, it would also make plpgsql much, much more powerful.
>
> Hello,
>
> What do
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 10, 2005 8:43 AM
> To: Thomas Hallgren
> Cc: Tom Lane; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Oracle Style packages on postgres
>
> [...]
Bruce Momjian schrieb:
OK, so it seems we need:
C static/private functions for schemas
C static/private variables for schemas
Are private variables implemented via the temporary per-session schema?
nested schemas
What does the standard say?
Is that it?
Yeah,
that would be
Bruce Momjian wrote:
Thomas Hallgren wrote:
Bruce Momjian wrote:
Josh Berkus wrote:
I think that private variables and private functions need to be part of the
definition.
OK, so it seems we need:
C static/private functions for schemas
C static/private varia
Thomas Hallgren wrote:
> Bruce Momjian wrote:
> > Josh Berkus wrote:
> >
> >>I think that private variables and private functions need to be part of the
> >>definition.
> >
> >
> > OK, so it seems we need:
> >
> > C static/private functions for schemas
> > C static/private variables fo
-- Forwarded message --
From: Adrian Maier <[EMAIL PROTECTED]>
Date: May 10, 2005 12:01 PM
Subject: Re: [HACKERS] Oracle Style packages on postgres
To: "Jim C. Nasby" <[EMAIL PROTECTED]>
On 5/9/05, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> On Sun, M
Bruce Momjian wrote:
Josh Berkus wrote:
I think that private variables and private functions need to be part of the
definition.
OK, so it seems we need:
C static/private functions for schemas
C static/private variables for schemas
Are private variables implemented via the temporar
Bruce,
> OK, so it seems we need:
>
> C static/private functions for schemas
> C static/private variables for schemas
>
> Are private variables implemented via the temporary per-session schema?
>
> nested schemas
>
> What does the standard say?
>
> Is that it?
Hmmm. That's an i
Bruce,
> > 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. fu
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'
Josh Berkus wrote:
> B-
>
> > Just saying "we need Oracle packages" doesn't make it happen. ?I have
> > followed the discussion and I still don't have a clear idea of the exact
> > additions that people want, and without that, nothing is likely to
> > happen. ?I don't even have something for the T
B-
> Just saying "we need Oracle packages" doesn't make it happen. I have
> followed the discussion and I still don't have a clear idea of the exact
> additions that people want, and without that, nothing is likely to
> happen. I don't even have something for the TODO list at this point.
That's
Josh Berkus wrote:
> Bruce,
>
> > > 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 insid
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> In Oracle you can use the syntax:
> ..()
> but you can just as well use the syntax:
> ..()
Hmm. I think there is also something pretty close to that in SQL2003.
It would be a lot easier to talk us into accepting something that's in
the spec than somet
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
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)
Tom,
> What I read in this thread is that the only truly missing feature is
> package variables (ie, session-local variables); is that an accurate
> statement? If so, it would seem simplest to add such a feature to
> plpgsql and be done with it. Several people already pointed out that
> most of
Josh Berkus writes:
> Yes, actually. If you look at the discussion, this is what killed the 2001
> proposal; packages were proposed as orthagonal to schema which was not
> acceptable.
I think what actually killed that proposal was that it was not made
clear what it did that wouldn't be done
I would be interested in hearing how we can implement Oracle packages in
a way that seamlessly integrates into what we have. Is it like
functions that are automatically called when a schema is accessed? And
the result put into a per-session temporary schema?
I think it is unlikely we would impl
On Mon, May 09, 2005 at 10:05:38AM -0700, Josh Berkus wrote:
> I've also never much liked Oracle's seperate package_header and package_body
> declaration structure: if the two are intrinsically tied, why not make it one
> declaration? Is syntactical compatibility important enough that we need t
I agree wholeheartedly and was actually just thinking of this yesterday.
Back when I was working on NEXTGRES I implemented package support into
plpgsql including scopes. While my time is pretty tight right now, I'd
be more than willing to work with whoever the plpgsql master is.
Jim C. Nasby wr
Rmm,
>"A black box processing engine with one or more public access functions
> that retains state across calls"
In other words, an Object.
> Oracle style package creation syntax is split into header and body so that
> the body(code) can be re-compiled without invalidating dependent objec
On Sun, May 08, 2005 at 10:38:41PM -0500, Bob wrote:
> One simple benefit to packages is just organization of related code.
Which, IMHO, is greatly diminished by the lack of
schema.package.function notation. BTW, the original post referred to
this as user.package.function, but I believe that techn
On E, 2005-05-09 at 07:36 +0200, Thomas Hallgren wrote:
> Satoshi Nagayasu wrote:
>
> >>An oracle package is created when first referenced. Its initialization
> >>code is run once (ie costly queries to populate session wide package
> >>params) and the package dies at the end of the ses
Satoshi Nagayasu wrote:
(B
(B>>An oracle package is created when first referenced. Its initialization
(B>>code is run once (ie costly queries to populate session wide package
(B>>params) and the package dies at the end of the session
(B>>An analogy with OOP is that it's like ha
Bob wrote:
(B> One simple benefit to packages is just organization of related code.
(B
(BAnd the package-scoped variables or constant values, similar to
(Bthe global variables.
(B
(BIt will be very useful for application programmers
(Bif one variable can be shared from several functions.
(B
One simple benefit to packages is just organization of related code.On 5/7/05, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:Oracle Style packages on postgresOVERVIEW:
To emulate oracle server side development in postgres I required serverside packages. The following text demonstrates how to do thi
62 matches
Mail list logo
