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
te
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 ses
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 d
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 techn
Rmm,
>"A black box processing engine with one or more public access functions
> that retains state across calls"
In other words, an Object.
> Oracle style package creation syntax is split into header and body so that
> the body(code) can be re-compiled without invalidating dependent objec
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 wr
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 di
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 th
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 may
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 o
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 t
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 impl
Josh Berkus 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 wouldn't be done
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
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
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 c
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 usern
"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,
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]
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 f
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
>> 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
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:
> ..()
> but you can just as well use the syntax:
> ..()
Hmm. I think there is also something pretty close to that in SQL2003.
It would be a lot easier to talk us into accepting something that's in
the spec than somet
"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 behave
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 proposi
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 cod
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 to
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 u
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 don'
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 insid
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
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 T
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'
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. fu
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 ...
Mar
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 i
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
Tom Lane <[EMAIL PROTECTED]> writes:
> > Partition Elimination relies upon being able to prove at execution time
>
> You mean plan time.
Fwiw, both are possible.
In oracle there are (at least) three different cases:
1. For queries like "select * from tab" the plan shows a multiple partition
sc
Tom Lane <[EMAIL PROTECTED]> writes:
> UPDATE totals SET
> xmax = ss.xmax, xmin = ss.xmin, ...
> FROM
> (SELECT groupid, max(x) AS xmax, ... FROM details GROUP BY groupid) ss
> WHERE groupid = ss.groupid;
>
...
>
> Of course this syntax isn't standard either ... but we a
48 matches
Mail list logo
