On Mon, 9 May 2005, Neil Conway wrote:
Oleg Bartunov wrote:
I just talked with AMD Russia and they could provide almost
any hw for testing, so I'm looking for test-suite for PostgreSQL.
Do we have sort of official tests ?
I guess the regression tests would be the closest to an official set of
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
Something weird is going on with some of mai emails - I tried to send this from
[EMAIL PROTECTED],
then from [EMAIL PROTECTED] and it does not appear in list. Another answer sent
after this
came through in less than 5 min.
Now I removed Tom Lane from To: and moved pgsql-hackers@postgresql.org
Just a heads up, I'm going to re-package the releases starting at 2pm ADT
this afternoon ... if anyone has any show stoppers like Jan, please speak
up within the next couple of hours :)
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]
-Original Message-
From: Tatsuo Ishii [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 08, 2005 11:08 PM
To: John Hansen
Cc: pgman@candle.pha.pa.us; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Patch for collation using ICU
I don't buy it. If
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
Hey everyone,
In addition to package support in plpgsql, it would be really handy to
have inline plpgsql. Likewise, I think there are others who feel this
way as-well.
Years ago, Oracle merged PL/SQL with their normal SQL parser which
allowed for inline PL/SQL. They did this because it was
As for implementation, I think it would obviously be best to leave
plpgsql on its own as a PL but maybe change BEGIN and DECLARE in the
normal parser and have the system generate/execute a function on the
fly. Or, maybe it would be better to integrate plpgsql. Or, I may just
be crazy.
Would
Jonah,
In addition to package support in plpgsql, it would be really handy to
have inline plpgsql. Likewise, I think there are others who feel this
way as-well.
I think a number of people would be interested in this. However, your
biggest development issue, as I've been told, is that the
Joshua D. Drake wrote:
As for implementation, I think it would obviously be best to leave
plpgsql on its own as a PL but maybe change BEGIN and DECLARE in the
normal parser and have the system generate/execute a function on the
fly. Or, maybe it would be better to integrate plpgsql. Or, I
If the idea originates in PostgreSQL, then nobody else can patent it,
because there will be pre-existing art (the PostgreSQL engine) that
already demonstrated the idea. A patent must have a novel idea in it.
I do not think a good thing can come from creation of software patents.
Here is a link
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
On E, 2005-05-09 at 11:44 -0600, Jonah H. Harris wrote:
Hey everyone,
In addition to package support in plpgsql, it would be really handy to
have inline plpgsql. Likewise, I think there are others who feel this
way as-well.
Session variables is what I miss most.
Years ago, Oracle
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)
On Mon, May 09, 2005 at 11:44:23AM -0600, Jonah H. Harris wrote:
Hey everyone,
In addition to package support in plpgsql, it would be really handy
to have inline plpgsql. Likewise, I think there are others who feel
this way as-well.
Why yes, there are. :)
Years ago, Oracle merged PL/SQL
On 5/9/05, Dann Corbit [EMAIL PROTECTED] wrote:
If the idea originates in PostgreSQL, then nobody else can patent it,
because there will be pre-existing art (the PostgreSQL engine) that
already demonstrated the idea. A patent must have a novel idea in it.
I do not think a good thing can
Today, usernames are case sensitive. This can cause some problems in for
example a kerberos environment (such as a Windows domain, in my case),
because the system usernames are case insensitive. So if I log in to my
workstation as Maghag I cannot connect to postgresql, because my
postgresql
Magnus Hagander [EMAIL PROTECTED] writes:
I would like to see a GUC variable to enable case insensitive usernames.
Would a patch for such a thing be accepted?
No, not any more than it would be for any other SQL identifiers. See
(many, many) past threads.
regards, tom
Tatsuo Ishii wrote:
Sent: Tuesday, May 10, 2005 12:32 AM
To: John Hansen
Cc: pgman@candle.pha.pa.us; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Patch for collation using ICU
-Original Message-
From: Tatsuo Ishii [mailto:[EMAIL PROTECTED]
Sent:
Many people have been discussing Table Partitioning lately. I've also
been giving thought to how to implement Table Partitioning within
PostgreSQL, as part of the Bizgres project for Business Intelligence.
After some discussion on Bizgres, I've now posted the most important and
common Use Cases
On Friday the 6th of May 2005, Mr. Treat opined:
I also don't think it is any harder to learn to query the
system tables than it would be to learn to query these new
views (with a few caevets that I will come back to) and it
might actually be better.
Admin tools are in a sense already a gui
I would like to see a GUC variable to enable case
insensitive usernames.
Would a patch for such a thing be accepted?
No, not any more than it would be for any other SQL identifiers. See
(many, many) past threads.
Yes, I've seen the many past threads on that ;-) I figured it might be
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
Magnus Hagander [EMAIL PROTECTED] writes:
Another way to help in this particular case would be to have libpq on
win32 only force-lowercase the username IF it was retreived from the
system (but not when manually specified).
Well, I personally don't care how bizarrely the Win32 port behaves ;-)
A more in-depth consideration of the major design options and trade-offs
available to us... this is an internals related discussion.
Comments?
1. Embellish inheritance or separate infrastructure?
Inheritance is a somewhat strange PostgreSQL feature, with a few
gotchas. The big one is the lack
Simon Riggs [EMAIL PROTECTED] writes:
1. Embellish inheritance or separate infrastructure?
It seems prudent to avoid building on that foundation, even though we
may decide to use some similar approaches.
I disagree. The code is there, it could use work, and what you are
basically proposing
On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
1. Embellish inheritance or separate infrastructure?
It seems prudent to avoid building on that foundation, even though we
may decide to use some similar approaches.
I disagree. The code is there,
David,
I agree with your idea. That seems like it would be somewhat easy to
implement and would do exactly what I would need. Anyone else have
ideas or thoughts along this line?
David Fetter wrote:
On Mon, May 09, 2005 at 11:44:23AM -0600, Jonah H. Harris wrote:
Hey everyone,
In addition
On Mon, May 09, 2005 at 05:28:42PM -0600, Jonah H. Harris wrote:
David,
I agree with your idea. That seems like it would be somewhat easy to
implement and would do exactly what I would need. Anyone else have
ideas or thoughts along this line?
Seeing as EXECUTE IMMEDIATE is already used,
David Fetter wrote:
EXECUTE IMMEDIATE $$
function body here
$$
LANGUAGE plfoo;
Seems like a lot of unnecessary syntax for something that would be
manually used by a lot of DBAs. Also, this is unrelated to normal
EXECUTE, or the EXECUTE IMMEDIATE defined by the standard, so I'm not
sure it's
Huh, not sure. The only thing the code does is check for
DNSServiceDiscovery.h and call a function therein. No implementation
details are taken care of in the Postgres source.
My bet is that it only works on Mac OS X. If there was interest I'm
sure we could make it work using libhowl but I
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
By the time you read this, they should all be done and sync'd to
ftp.postgresql.org ... v8.0.3 is just finishing its packaging right now,
so that one might be a bit delayed (depending on how fast you receive
this, of course)
Scan through them and let me know if there are any issues ...
Neil Conway [EMAIL PROTECTED] writes:
BTW, this is a little off-the-wall, but one interesting idea to help SQL
and PL/foo integration would be to replace the bison grammar for SQL
with a hand-written recursive descent parser.
Ick. I gave up hand-written RD parsers twenty-five years ago.
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
Robert,
As Jim points out, their current long term goal is to be a replacement for
the current system views (hence *new* system views), and the current
project was created to facilitate development. What I am thinking is that
the project take on a different goal, mainly that it be an add on
46 matches
Mail list logo
