On Sat, 20 Oct 2001, Rod Taylor wrote:
> But what if you want a C function to set a variable which can be
> accessed using an SQL, perl, PLpgSQL or other function type?
> Shouldn't a global variable be global between all types of functions?
No. Doing that requires that all languages have the sam
what really happened.
- Original Message -
From: "Bill Studenmund" <[EMAIL PROTECTED]>
To: "Peter Eisentraut" <[EMAIL PROTECTED]>
Cc: "PostgreSQL Development" <[EMAIL PROTECTED]>
Sent: Friday, October 19, 2001 1:59 PM
Subject: Re: [HACKERS]
On Sat, 20 Oct 2001, Peter Eisentraut wrote:
> Yes, you're right. Actually, sharing data across PostgreSQL C functions
> is trivial because you can just use global variables in your dlopen
> modules.
Exactly. That's why I never envisioned "C" or "internal" functions using
package global variabl
>I think Jean-Michael's comments were right. While I'm not sure if things
>will be as overwhelming as he predicted, packages (even as implimented in
>my patch) will help people develop code libraries for PostgreSQL. And that
>will make PostgreSQL applications easier.
PostgreSQL is a fantastic to
Bill Studenmund writes:
> > create function produce(text) returns text as '
> > GD["key"] = args[0]
> > ' language plpython;
> >
> > create function consume() returns text as '
> > return GD["key"]
> > ' language plpython;
> >
> > There is also a dictionary for private data.
>
> Private t
On Sat, 13 Oct 2001, Peter Eisentraut wrote:
> Bill Studenmund writes:
>
> > So what are packages? In Oracle, they are a feature which helps developers
> > make stored procedures and functions.
>
> I think you have restricted yourself too much to functions and procedures.
> A package could/should
On Thu, 18 Oct 2001, Peter Eisentraut wrote:
> Bill Studenmund writes:
>
> > Honestly, I do not understand why "global variables" have been such a sore
> > point for you.
>
> My point is that the proposed "package support" introduces two features
> that are a) independent, and b) already exist, a
Bill Studenmund writes:
> Honestly, I do not understand why "global variables" have been such a sore
> point for you.
My point is that the proposed "package support" introduces two features
that are a) independent, and b) already exist, at least in design.
Schemas are already planned as a namesp
On Thu, 18 Oct 2001, Peter Eisentraut wrote:
> Bill Studenmund writes:
>
> > Could you please give me an example of how to do this, say for plperl or
> > plpython? Just showing how two functions made with CREATE FUNCTION can use
> > global variables will be fine. This example will help me underst
Bill Studenmund writes:
> Could you please give me an example of how to do this, say for plperl or
> plpython? Just showing how two functions made with CREATE FUNCTION can use
> global variables will be fine. This example will help me understand how
> they work.
For PL/Tcl you use regular Tcl gl
On Wed, 17 Oct 2001, Peter Eisentraut wrote:
> Bill Studenmund writes:
>
> > Yes, I want a namespace below schemas.
> >
> > The difference between packages and schemas is that schemas encapsulate
> > everything. As Tom pointed out, that includes types (and I'd assume
> > operators too). Packages
Bill Studenmund writes:
> Yes, I want a namespace below schemas.
>
> The difference between packages and schemas is that schemas encapsulate
> everything. As Tom pointed out, that includes types (and I'd assume
> operators too). Packages do not encapsulate types and operators.
Of course nobody i
On Sat, 13 Oct 2001, Peter Eisentraut wrote:
> Bill Studenmund writes:
>
> > session-specific package variables,
>
> I think this is assuming a little too much about how a PL might operate.
> Some PLs already support this in their own language-specific way, with or
> without packages. Thus, I do
On Tue, 16 Oct 2001, Peter Eisentraut wrote:
> Bill Studenmund writes:
>
> > I disagree. Views and tables are the purview of schemas, which as I
> > mentioned to Tom, strike me as being different from packages.
>
> Well, obviously schemas are a namespacing mechanism for tables and views.
> And ap
Bill Studenmund writes:
> I disagree. Views and tables are the purview of schemas, which as I
> mentioned to Tom, strike me as being different from packages.
Well, obviously schemas are a namespacing mechanism for tables and views.
And apparently the "packages" you propose are (among other thing
On Sun, 14 Oct 2001, Peter Eisentraut wrote:
> I have been pondering a little about something I called "package",
> completely independent of anything previously implemented. What I would
> like to get out of a package is the same thing I get out of package
> systems on operating systems, namely
On Sat, 13 Oct 2001, Jean-Michel POURE wrote:
> >What do folks think?
> >Take care,
> >Bill
>
> Hello Bill,
>
> The community have been waiting for packages for a long time. I don't
> believe you did it!!!
>
> IMHO most applications do not fully benefit from the power of PostgreSQL
> because tran
On Sat, 13 Oct 2001, Tom Lane wrote:
> Bill Studenmund <[EMAIL PROTECTED]> writes:
> > For functions and aggregates, things are a little more complicated. First
> > off, there is a package called "standard" which contains all types,
> > aggregates, operators, and functions which aren't in a speci
Tom Lane writes:
> This seems like it will overlap and possibly conflict with the decisions
> you've made for packages. It also seems possible that a package *is*
> a schema, if schemas are defined that way --- does a package bring
> anything more to the table?
I have been pondering a little ab
Bill Studenmund writes:
> So what are packages? In Oracle, they are a feature which helps developers
> make stored procedures and functions.
I think you have restricted yourself too much to functions and procedures.
A package could/should also be able to contain views, tables, and such.
> They
Bill Studenmund <[EMAIL PROTECTED]> writes:
> ... operators and types in
> packages are in the same name space as are types and operators not in
> packages.
> For functions and aggregates, things are a little more complicated. First
> off, there is a package called "standard" which contains all t
>What do folks think?
>Take care,
>Bill
Hello Bill,
The community have been waiting for packages for a long time. I don't
believe you did it!!!
IMHO most applications do not fully benefit from the power of PostgreSQL
because transactions are performed at application lever
(PHP/asp/Java/Appl
Zembu has decided to release the result of a recent Postgres developement
project to the Postgres project. This project (for which I was the lead
developer) adds Oracle-like package support to Postgres. I'm in the
process of making a version of the patch which is relative to the current
cvs tree.
23 matches
Mail list logo
