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)-
28 matches
Mail list logo
