Jim C. Nasby wrote:
4. Syntax must be as closer as plpgsql (declaration, assingment etc)
rather than any syntax that we have to learn :-)
PostgreSQL support other languages than PL/pgSQL. We need universal syntax
for plperl and others too
Why? Don't those other languages have suppo
From: "Jim C. Nasby" <[EMAIL PROTECTED]>
To: Pavel Stehule <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] proposal for PL packages for 8.3.
Date: Wed, 9 Aug 2006 11:27:01 -0500
On Wed, Aug 09, 2006 at 06:34:16AM +020
On Wed, Aug 09, 2006 at 06:34:16AM +0200, Pavel Stehule wrote:
> > Is it would be nice , if packages have been ;
>
> > 1. Package level variables (Public variables)
>
> is very hard for imlementation, and it's actually impossible. Needs large
> changes in code
> > 2. Package member level vari
On Wed, Aug 09, 2006 at 11:48:41AM +0200, Pavel Stehule wrote:
>
> >There are three separate issues we seem to be talking about.
> >
> >1. Namespaces - visibility or otherwise of objects
> >2. Procedural state - something that looks like a shared variable
> >3. Packaging - installation/dependency
On Wed, Aug 09, 2006 at 10:55:30AM -0400, Bruce Momjian wrote:
> Martijn van Oosterhout wrote:
> -- Start of PGP signed section.
> > On Wed, Aug 09, 2006 at 08:38:22AM +0100, Richard Huxton wrote:
> > > There are three separate issues we seem to be talking about.
> > >
> > > 1. Namespaces - visibi
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Wed, Aug 09, 2006 at 08:38:22AM +0100, Richard Huxton wrote:
> > There are three separate issues we seem to be talking about.
> >
> > 1. Namespaces - visibility or otherwise of objects
> > 2. Procedural state - something that loo
> Well, it would be nice to have some clarification about the expected
> scope and lifetimes of these variables. If two different sessions
> change the values, what's supposed to happen?
Right, I am confused whether these are session or schema-local
variables. What does Oracle support? Loo
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Wed, Aug 09, 2006 at 08:38:22AM +0100, Richard Huxton wrote:
> > There are three separate issues we seem to be talking about.
> >
> > 1. Namespaces - visibility or otherwise of objects
> > 2. Procedural state - something that looks
Richard Huxton wrote:
Packaging
I'd guess we'd need a pg_package and pg_package_items system tables. We
could track:
- package name (different from schema)
- version number
- install/uninstall functions
- start-session/end-session functions
- dependencies (is pg_depend enough)
pg_package_items
There are three separate issues we seem to be talking about.
1. Namespaces - visibility or otherwise of objects
2. Procedural state - something that looks like a shared variable
3. Packaging - installation/dependency handling
and 4. support more languages:
4a) binary incompatibility between v
Martijn van Oosterhout wrote:
On Wed, Aug 09, 2006 at 08:38:22AM +0100, Richard Huxton wrote:
Namespaces
Given that we already have search_path it makes sense to use it. So, we
could have something like:
1. A "PRIVATE" modifier for objects that mean they are only accessible
if their schema is
On Wed, Aug 09, 2006 at 08:38:22AM +0100, Richard Huxton wrote:
> There are three separate issues we seem to be talking about.
>
> 1. Namespaces - visibility or otherwise of objects
> 2. Procedural state - something that looks like a shared variable
> 3. Packaging - installation/dependency handlin
Bruce Momjian wrote:
Josh Berkus wrote:
Bruce,
I like the idea of a package being a schema. I imagine that a package
would put its own schema name first in the 'search_path' before
referencing an object. I think anything more complex is going to be too
hard to use.
Or we could just add loca
Is it would be nice , if packages have been ;
1. Package level variables (Public variables)
is very hard for imlementation, and it's actually impossible. Needs large
changes in code
2. Package member level variables (Private variable)
I plan it, in every PL language
3. Public and
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "Josh Berkus"
Cc: "Tom Lane" <[EMAIL PROTECTED]>; "Pavel Stehule"
<[EMAIL PROTECTED]>; ;
Sent: Wednesday, August 09, 2006 1:49 AM
Subject: Re: [HACKERS]
Josh Berkus wrote:
> Bruce,
>
> > I like the idea of a package being a schema. I imagine that a package
> > would put its own schema name first in the 'search_path' before
> > referencing an object. I think anything more complex is going to be too
> > hard to use.
> >
>
> Or we could just add
Bruce,
I like the idea of a package being a schema. I imagine that a package
would put its own schema name first in the 'search_path' before
referencing an object. I think anything more complex is going to be too
hard to use.
Or we could just add local variables to schema and dispense with
Tom,
I'm confused. I thought the consensus was that we'd get package
functionality via SQL99 TYPEs, rather than by implementing
oracle-copycat syntax.
--Josh
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your d
Tom Lane wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
> >> 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.
>
From: Tom Lane <[EMAIL PROTECTED]>
To: "Pavel Stehule" <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], dev@archonet.com, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] proposal for PL packages for 8.3. Date: Tue, 08 Aug
2006 08:18:42 -0400
"Pavel Stehule"
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I unlike concept of nested schemats or packages nested in schema. I
don't
> see reason for it. About implementation.. package is more special kind
of
> function for me. But relation between package and function I can create
via
> dot notation in
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I unlike concept of nested schemats or packages nested in schema. I don't
> see reason for it. About implementation.. package is more special kind of
> function for me. But relation between package and function I can create via
> dot notation in fun
>
> 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
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
>> 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
n
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> 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 som
Pavel Stehule wrote:
Package is similar to schema.
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.
Pavel
__
Pavel Stehule wrote:
Package is similar to schema.
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"?
--
Richard Huxton
Archonet Ltd
---(end of broadcast)-
Hello
Package contains package's variables, shared protected functions and
initialisation part, which is executed when any public function attached to
package is called. Every package has defined only one language. The reason
for this is binary compatibility of package's variables. Private fun
29 matches
Mail list logo
