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 session variables
o
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 do
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 focus on the use cases for Oracle
packages, rather than the specific functionality it provides.
What things do people
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 nested schemas
Hmmm
]; 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 do that it already
-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 Held [EMAIL PROTECTED] writes:
/*
* We
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 of this
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 the same
-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 a lot of handwaving about nested schemas
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 instance
-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 PROTECTED] writes:
The rule is simple: when
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)
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 be
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 catalog.
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 seems on first
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 active catalog.
Bruce Momjian pgman@candle.pha.pa.us 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
On Wed, May 11, 2005 at 04:49:52PM -0400, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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 where the
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, not recursive
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';
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
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 immediate thought is
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.column
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
-- 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, May 08, 2005 at 10:38:41PM -0500, Bob
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 for schemas
Are
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
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
-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
[...]
I suppose. I think we should
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 you think
On Mon, May 09, 2005 at 11:24:45PM +0200, Thomas Hallgren wrote:
In Oracle you can use the syntax:
schema.package.function()
but you can just as well use the syntax:
schema.type.static method()
Why do you need both? If PostgreSQL is going to add new nice features
that enables better
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 does the
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 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.
Do
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
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: [HACKERS] Oracle Style packages on postgres
[...]
I
?
---
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: [HACKERS] Oracle Style
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
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
o
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 Allow
Bruce Momjian pgman@candle.pha.pa.us 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?
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 session
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
Rmm,
A black box processing engine with one or more public access functions
that retains state across calls
In other words, an Object. grin
Oracle style package creation syntax is split into header and body so that
the body(code) can be re-compiled without invalidating dependent
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
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 to
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
Josh Berkus josh@agliodbs.com 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
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 the
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)
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
Thomas Hallgren [EMAIL PROTECTED] writes:
In Oracle you can use the syntax:
schema.package.function()
but you can just as well use the syntax:
schema.type.static method()
Hmm. I think there is also something pretty close to that in SQL2003.
It would be a lot easier to talk us into accepting
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 inside the package
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 what
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 TODO list at
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
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. functions
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 interesting
Oracle Style packages on postgres
OVERVIEW:
To emulate oracle server side development in postgres I required server
side packages. The following text demonstrates how to do this using
plpython on postgres 8 and suggests a language extension.
WHAT ARE ORACLE PACKAGES?
Looking back over the
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 this
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
Satoshi Nagayasu wrote:
(B
(BAn oracle package is created when first referenced. Its initialization
(Bcode is run once (ie costly queries to populate session wide package
(Bparams) and the package dies at the end of the session
(BAn analogy with OOP is that it's like having a
63 matches
Mail list logo
