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
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
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
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
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.
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
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
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'
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
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:
> 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
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'
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
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,
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, 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
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
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
"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
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
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
>> 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
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
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
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]
"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,
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
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
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
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 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,
> 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
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
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
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
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
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
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
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
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
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
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
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
> > -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
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]
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
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
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
48 matches
Mail list logo
