Joshua D. Drake wrote:
Or better yet, if editing the TODO is more accessible then we're not
dependent on one person to maintain it.
To be fair, Bruce has offered to allow that to happen even on his home
machine (Bruce that is a bad idea btw) and ANYONE can submit a patch.
It may not be a
Jim C. Nasby wrote:
On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote:
From Bruce's perspective this actually doesn't add too much to the
workload. Generate the link, possibly paste some archive urls into the
wiki and then someone can come behind and clean up.
Or better
Joshua D. Drake wrote:
We now have URLs on the TODO list to the archives, and the next FAQ item
is:
H3 id=item1.41.4) What do I do after choosing an item to
work on?/H3
PSend an email to pgsql-hackers with a proposal for what you want
to do (assuming your
Joshua D. Drake wrote:
Jim C. Nasby wrote:
On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote:
From Bruce's perspective this actually doesn't add too much to the
workload. Generate the link, possibly paste some archive urls into the
wiki and then someone can come behind and
Jim C. Nasby wrote:
On Tue, Aug 08, 2006 at 10:31:00PM -0400, Bruce Momjian wrote:
bruce wrote:
bruce wrote:
OK, seems this should be a separate application, not done in the TODO
list, and I am not willing to take on that additional workload.
Let me add that anyone who
It would also be useful to have possible dependencies. I recently saw
a patch come across from Sun, that Tom commented on, something about
increase the size of some value to 64bit. I don't recall exactly.
I am keeping URLs in the TODO list. Why don't people submit
improvements to the TODO
Andrew Dunstan wrote:
Bruce Momjian wrote:
I am keeping URLs in the TODO list. Why don't people submit
improvements to the TODO list, rather than adding more complexity by
making a separate wiki for every TODO item? If no one updates the TODO
item, what makes you think they are
Andrew Dunstan wrote:
Joshua D. Drake wrote:
Or better yet, if editing the TODO is more accessible then we're not
dependent on one person to maintain it.
To be fair, Bruce has offered to allow that to happen even on his home
machine (Bruce that is a bad idea btw) and ANYONE can
Until you have used this, it seems strange. After you start it doesn't ;-)
Sure, but with openness comes cruft, which can be a problem too. Do we
want everyone's idea of a useful feature listed? I don't.
Why not as long as we have someone who can actually make approved
todos versus
Joshua D. Drake wrote:
Hi, I am a C developer, PostgreSQL Rocks... I would like to take the
Enums todo. Here are my specific questions regarding your feature
requirements at URL ---
Well, few have shown any interest in improving the TODO list, so who is
going to be motivated to do
Joshua D. Drake wrote:
Until you have used this, it seems strange. After you start it doesn't ;-)
Sure, but with openness comes cruft, which can be a problem too. Do we
want everyone's idea of a useful feature listed? I don't.
Why not as long as we have someone who can actually
Bruce Momjian wrote:
Joshua D. Drake wrote:
Until you have used this, it seems strange. After you start it doesn't ;-)
Sure, but with openness comes cruft, which can be a problem too. Do we
want everyone's idea of a useful feature listed? I don't.
Why not as long as we have someone who can
Joshua D. Drake wrote:
Bruce Momjian wrote:
Joshua D. Drake wrote:
Until you have used this, it seems strange. After you start it doesn't
;-)
Sure, but with openness comes cruft, which can be a problem too. Do we
want everyone's idea of a useful feature listed? I don't.
Why not as
1. Better descriptions about the todo/feature? E.g; feature specification
I am not sure there is enough churn of TODO items to make larger
descriptions worth it. As it is, I have to link to new URLs as the TODO
item is clarified.
Are you kidding? Did you see the discussion just on the todo
Joshua D. Drake wrote:
1. Better descriptions about the todo/feature? E.g; feature specification
I am not sure there is enough churn of TODO items to make larger
descriptions worth it. As it is, I have to link to new URLs as the TODO
item is clarified.
Are you kidding? Did you see
Heikki Linnakangas wrote:
Bruce Momjian wrote:
I am keeping URLs in the TODO list. Why don't people submit
improvements to the TODO list, rather than adding more complexity by
making a separate wiki for every TODO item? If no one updates the TODO
item, what makes you think they are
3. Heck *your portion* of the TODO would be easily satisfied by having a
single line with a link that points to the specific wiki page.
But who is going to do that if no one has done anything in the past for
the TODO list. I keep asking that.
I believe that Andrew and I as well as a few
Bruce Momjian wrote:
I am keeping URLs in the TODO list. Why don't people submit
improvements to the TODO list, rather than adding more complexity by
making a separate wiki for every TODO item? If no one updates the TODO
item, what makes you think they are going to do somethin in a wiki?
OK, so what do you want to do?
Oh, sure makes us deliver on our arguments. How very un open source of
you :).. Let me get with andrew and I will post back and actual
solidified idea.
Andrew and I are tabling this until I get back from LinuxWorld. We will
be discussing potential ideas to
Joshua D. Drake [EMAIL PROTECTED] writes:
It would also be useful to have possible dependencies. I recently saw
a patch come across from Sun, that Tom commented on, something about
increase the size of some value to 64bit. I don't recall exactly.
Tom's comments although valid (as usual :))
I am actually hoping that jabber.postgresql.org would help that in the
long run.
Jabber's ok, but why not go with SILC instead?
---(end of broadcast)---
TIP 6: explain analyze is your friend
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
It would also be useful to have possible dependencies. I recently saw
a patch come across from Sun, that Tom commented on, something about
increase the size of some value to 64bit. I don't recall exactly.
Tom's comments although valid
Andrew Hammond wrote:
I am actually hoping that jabber.postgresql.org would help that in the
long run.
Jabber's ok, but why not go with SILC instead?
Because everything supports jabber, I only know of SILC and gaim that
support SILC :). Also Jabber is pretty much an accepted standard at
On Wed, 2006-08-09 at 12:15 -0400, Bruce Momjian wrote:
Well, either people post the changes publically or I trust a few people.
I don't trust everyone or the TODO becomes a dumping ground, which I am
afraid might happen with a wiki that anyone can update.
I think that's preventable,
On Wed, Aug 09, 2006 at 01:56:42PM -0700, Neil Conway wrote:
On Wed, 2006-08-09 at 12:15 -0400, Bruce Momjian wrote:
Well, either people post the changes publically or I trust a few people.
I don't trust everyone or the TODO becomes a dumping ground, which I am
afraid might happen with a
On Wednesday 09 August 2006 12:12, Bruce Momjian wrote:
One possibility: have a 'holding area' (perhaps on a Wiki) where users
could add use-cases for these ideas. If there's 'enough demand' (however
one defines that), they get promoted to the TODO. Note that this is
something geared
Robert Treat wrote:
On Wednesday 09 August 2006 12:12, Bruce Momjian wrote:
One possibility: have a 'holding area' (perhaps on a Wiki) where users
could add use-cases for these ideas. If there's 'enough demand' (however
one defines that), they get promoted to the TODO. Note that this is
On Wed, 9 Aug 2006, Dave Page wrote:
Marc was setting up developer.postgresql.org as a developers wiki btw...
Dunno what happened to that.
Marc?
Two words: House Hunting ...
I have to download the stuff from pgFoundry tomorrow night, already have
the database server running locally ...
Mark Kirkwood [EMAIL PROTECTED] writes:
Robert Treat wrote:
Wouldn't a thread reply saying something like Bruce, can we add this as a
TODO with the following wording: blah blah blah likely suffice?
That's pretty much how it's done now ...
Yeah - and/or a patch to TODO or the relevant
Bruce Momjian wrote:
I know about the same as the community members who pay attention to
postings. What I do is to act on that information by contacting
developers and asking them to complete their work for feature freeze.
Many of my conversations are not appropriate for the public, which is
Andrew Dunstan wrote:
Bruce Momjian wrote:
I know about the same as the community members who pay attention to
postings. What I do is to act on that information by contacting
developers and asking them to complete their work for feature freeze.
Many of my conversations are not
Bruce Momjian wrote:
Or try a new system, and I will keep doing what I do, and we can see
which system works best.
Excellent idea. We don't have to have a one size fits all set of
procedures anyway - in fact I think it might be a mistake. Maybe we
should select a few major features
Andrew Dunstan wrote:
My big point is that we should choose a system that would have had a
better chance of completing features than what we have used in the past,
and no one has suggested one.
It is just like the bug tracker issue. Many think we need a bugtracker,
but when I ask to
Bruce Momjian wrote:
I am saying other people can try a new system, but I don't have time to
try something different when no evidence has been given that it is
better (just different).
Ok, not sure if I am in a position to call shots like I am about to,
but here it goes:
Could everybody who
For example:
Make postmater and postgres options distinct so the postmaster -o
option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06
We could do that, but once an item is done I don't see the point in
having the date and person's name. You are right that is clearly a
different
Joshua D. Drake wrote:
For example:
Make postmater and postgres options distinct so the postmaster -o
option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06
We could do that, but once an item is done I don't see the point in
having the date and person's name. You
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Bruce Momjian)
wrote:
Joshua D. Drake wrote:
For example:
Make postmater and postgres options distinct so the postmaster -o
option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06
We could do that, but
Christopher Browne wrote:
Make postmater and postgres options distinct so the postmaster -o
option is no longer needed | Alvaro | Confirmed | 09/20/06
Notice the sequence of events. I am not saying the specific statuses are
the way to go but it would give a simple way to keep tabs on
[EMAIL PROTECTED] (Bruce Momjian) writes:
Christopher Browne wrote:
Make postmater and postgres options distinct so the postmaster -o
option is no longer needed | Alvaro | Confirmed | 09/20/06
Notice the sequence of events. I am not saying the specific statuses are
the way to go but
If what we see in the todo is...
Implement hierarchical queries using ANSI WITH/recursive query
system | Someone | Under way | [some date six months ago]
... then those that are interested in seeing this go in can probably
guess that the effort has stalled in that nothing has been worth
Bruce,
What happens now is that someone says they want to work on X, and the
community tells them that Y might be working on it, and Y gives us a
status.
What happens now is:
A starts working on X.
3 months pass
B comes to hackers, spends hours reading the archives, doesn't find X
(because
On Aug 8, 2006, at 17:47 , Josh Berkus wrote:
What happens now is:
A starts working on X.
3 months pass
B comes to hackers, spends hours reading the archives, doesn't find
X (because they know it by a different name), comes to -hackers and
asks Is anyone working on X?
B waits for 2 weeks
Josh Berkus wrote:
Bruce,
What happens now is that someone says they want to work on X, and the
community tells them that Y might be working on it, and Y gives us a
status.
What happens now is:
A starts working on X.
3 months pass
B comes to hackers, spends hours reading the archives,
OK, seems this should be a separate application, not done in the TODO
list, and I am not willing to take on that additional workload.
---
Josh Berkus wrote:
Bruce,
What happens now is that someone says they want to
Bruce,
OK, seems this should be a separate application, not done in the TODO
list, and I am not willing to take on that additional workload.
That's my feeling. But I think that we have enough people who are
interested to maintain it. If we don't, there was no point anyway.
--Josh
bruce wrote:
OK, seems this should be a separate application, not done in the TODO
list, and I am not willing to take on that additional workload.
Let me add that anyone who has CVS commit access or wants to submit
TODO patches can keep the TODO updated in this way.
Josh Berkus wrote:
Bruce,
OK, seems this should be a separate application, not done in the TODO
list, and I am not willing to take on that additional workload.
That's my feeling. But I think that we have enough people who are
interested to maintain it. If we don't, there was no point
Lukas Smith wrote:
Josh Berkus wrote:
OK, seems this should be a separate application, not done in the TODO
list, and I am not willing to take on that additional workload.
That's my feeling. But I think that we have enough people who are
interested to maintain it. If we don't, there
I'd vote for a Trac site. I've found it to be a rather useful tool in
general, though a bit too simple-minded; integrated Wiki, a simple
bugtracker, and roadmap-style reports for people who cares about such
stuff.
I don't think we'd use the SCM module though.
Oddly enough if anything we
Can you guys conceive of the thousands of hours of chat you guys are
racking upinstead of real hacking because you have an inadequate working
structure? This is by far the chattiest and least worthwhile listserv
in the bsd world. Bar none.
--
No virus found in this outgoing message.
Joshua D. Drake wrote:
I don't think we'd use the SCM module though.
Oddly enough if anything we could use the SCM module for
viewing/changest etc... I already have it regenerating itself over at
http://projects.commandprompt.com/public/pgsql
I've found that repository view to be broken
Alvaro Herrera wrote:
Joshua D. Drake wrote:
I don't think we'd use the SCM module though.
Oddly enough if anything we could use the SCM module for
viewing/changest etc... I already have it regenerating itself over at
http://projects.commandprompt.com/public/pgsql
I've found that
bruce wrote:
bruce wrote:
OK, seems this should be a separate application, not done in the TODO
list, and I am not willing to take on that additional workload.
Let me add that anyone who has CVS commit access or wants to submit
TODO patches can keep the TODO updated in this way.
I can
I'm constantly amazed at the way people get worked up about
X-is-not-there *after* feature freeze. If you wanted it in 8.2,
the time to be throwing resources at the problem was six months ago.
It's not like Oleg and Teodor haven't let it be known that they
could use financing.
I would say
-Original Message-
From: Tom Lane [EMAIL PROTECTED]
To: Greg Sabino Mullane [EMAIL PROTECTED]
Cc: pgsql-hackers@postgresql.org pgsql-hackers@postgresql.org
Sent: 07/08/06 04:42
Subject: Re: [HACKERS] 8.2 features status
I'm constantly amazed at the way people get worked up about
X
On Fri, Aug 04, 2006 at 11:57:03AM -0500, Kenneth Marshall wrote:
On Fri, Aug 04, 2006 at 12:40:36PM -0400, Tom Lane wrote:
Guillaume Smet [EMAIL PROTECTED] writes:
And what about compression of on-disk sorting?
That's purely a performance issue, which some people seem to want
to
On Sat, Aug 05, 2006 at 11:31:24AM -0400, Andrew Dunstan wrote:
Bruce Momjian wrote:
The fact is, the existing system worked as it should, though it is often
invisible. We didn't get all the features we wanted, but that isn't
because the system isn't working.
Thank you Bruce. That is good
On Fri, Aug 04, 2006 at 09:58:08PM -0400, Tom Lane wrote:
[EMAIL PROTECTED] writes:
Greg, you are on an utterly wrong track here. Try to look about a bit more
broadly.
FWIW, I tend to agree with Greg. This project has gotten to where it is
with a very loose structure, and I think that
On Fri, Aug 04, 2006 at 10:30:26PM -0400, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
As I was saying on #postgresql, the current system works well for a
small group of developers. I don't think there is any arguing that.
However, there is a larger group out there, that
On Sat, Aug 05, 2006 at 03:55:17PM -0700, Ron Mayer wrote:
[EMAIL PROTECTED] wrote:
Ron Mayer wrote:
We have not had that many cases where lack of
communication was a problem.
One could say too much communication was the problem this time.
I get the impression people implied they'd do
Jim C. Nasby wrote:
Going one step further, if that item was in a system that allowed people
to get emails any time status changed then *everyone* who was interested
in that feature would immediately know that help was needed. I fail to
see how that's a bad thing.
Or maybe even more
Bruce,
The fact is, the existing system worked as it should, though it is often
invisible. We didn't get all the features we wanted, but that isn't
because the system isn't working.
But it's exactly the invisibility of the process which people are
complaining about. If the postgresql
Josh Berkus wrote:
Bruce,
The fact is, the existing system worked as it should, though it is often
invisible. We didn't get all the features we wanted, but that isn't
because the system isn't working.
But it's exactly the invisibility of the process which people are
complaining
Joshua D. Drake wrote:
The fact is, the existing system worked as it should, though it is often
invisible. We didn't get all the features we wanted, but that isn't
because the system isn't working.
Well that kind of comes back to my point of better communication.
Perhaps a lot of
On Sat, 5 Aug 2006, Peter Eisentraut wrote:
Joshua D. Drake wrote:
Frankly, I don't care if we ever get a bug tracker or use trac.
However a more formalized communication process is sorely needed
IMHO.
There's also supposed to be a wiki set up.
Working on that, hope to have it up Sunday
On Fri, Aug 04, 2006 at 12:40:36PM -0400, Tom Lane wrote:
Guillaume Smet [EMAIL PROTECTED] writes:
And what about compression of on-disk sorting?
That's purely a performance issue, which some people seem to want
to define as not a new feature ... which is not *my* view of
what's important
# kleptog@svana.org / 2006-08-05 15:49:33 +0200:
On Fri, Aug 04, 2006 at 06:25:35PM -0700, Joshua D. Drake wrote:
I have heard you make this argument before, and it is just is not true.
Even Debian is moving toward a more formal structure as has FreeBSD. You
seem stuck in this world where
On Aug 5, 2006, at 10:48 PM, Christopher Browne wrote:
Quoth [EMAIL PROTECTED] (David Fetter):
On Fri, Aug 04, 2006 at 02:37:56PM -0700, Neil Conway wrote:
On Fri, 2006-08-04 at 12:40 -0700, David Fetter wrote:
While I am not going to reopen the can of worms labeled 'bug
tracker', I think
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My impression from this post
http://archives.postgresql.org/pgsql-hackers/2006-07/msg00556.php
was that moving it into core should be doable for 8.3. I hope I
didn't misunderstand.
As I've stated before, it sure would be nice if there was any
Greg,
As I've stated before, it sure would be nice if there was any
possible way this could be done for 8.2. This would be a
*huge* feature for
8.2 to have, and it frankly needs all the
big-item-yet-easy-to-grasp features it can get. Is there any
way this could be done if we threw money
Greg Sabino Mullane wrote:
My impression from this post
http://archives.postgresql.org/pgsql-hackers/2006-07/msg00556.php
was that moving it into core should be doable for 8.3. I hope I
didn't misunderstand.
As I've stated before, it sure would be nice if there was any possible
way
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Is there any way this could be done if we threw money
and/or people at the problem?
No.
I'm constantly amazed at the way people get worked up about
X-is-not-there *after* feature freeze. If you wanted it in 8.2,
the time to be throwing resources
If people are going to start listing features they want here's some
things I think would be nice. I have no idea though if they would be
useful to anyone else:
1) hierarchical / recursive queries. I realize it's just been
discussed at length but since there was some question as to
Joshua D. Drake wrote:
Frankly, I don't care if we ever get a bug tracker or use trac.
However a more formalized communication process is sorely needed
IMHO.
There's also supposed to be a wiki set up. There, people can try to
make up tracking lists, project management, task lists, release
[EMAIL PROTECTED] writes:
I don't object to someone informally polling people who have claimed a
TODO item and not produced any visible progress for awhile. But I
think
anything like thou shalt report in once a week will merely drive
people away from publicly claiming items, if not drive
On Sat, Aug 05, 2006 at 12:19:54AM -0400, Matthew T. O'Connor wrote:
Robert Treat wrote:
So, the things I hear most non-postgresql people complain about wrt
postgresql are:
no full text indexing built in
FTI is a biggie in my mind. I know it ain't happening for 8.2, but is
the general
Tom Lane wrote:
But a quick troll through the CVS logs shows ...
multi-row VALUES, not only for INSERT but everywhere SELECT is allowed ...
multi-argument aggregates, including SQL2003-standard statistical aggregates ...
standard_conforming_strings can be turned on (HUGE deal for some people)
On Fri, Aug 04, 2006 at 06:25:35PM -0700, Joshua D. Drake wrote:
I have heard you make this argument before, and it is just is not true.
Even Debian is moving toward a more formal structure as has FreeBSD. You
seem stuck in this world where everything is still 1994 and all FOSS
software is
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
I don't object to someone informally polling people who have claimed a
TODO item and not produced any visible progress for awhile. But I
think
anything like thou shalt report in once a week will merely drive
people away from publicly
There's also supposed to be a wiki set up. There, people can try to
make up tracking lists, project management, task lists, release goals
or whatever on their own. If patterns emerge, we can formalize them,
but I feel this would be a good way to try things out.
Well I will re-extend my
Bruce Momjian wrote:
I can assure you that individual developers were contacted about
completing their items for 8.2, to the extent that some developers got
upset at me because of my insistence. If they were hired by PostgreSQL
companies and I had a relationship with their manager, their
The fact is, the existing system worked as it should, though it is often
invisible. We didn't get all the features we wanted, but that isn't
because the system isn't working.
Well that kind of comes back to my point of better communication.
Perhaps a lot of this discussion could have been
Martijn van Oosterhout kleptog@svana.org writes:
On Sat, Aug 05, 2006 at 12:19:54AM -0400, Matthew T. O'Connor wrote:
FTI is a biggie in my mind. I know it ain't happening for 8.2, but is
the general plan to integrate TSearch2 directly into the backend?
When the Tsearch developers say so I
Tom Lane wrote:
I tend to agree --- I don't see much value in trying to institute a
formalized process.
One more problem with the formalized process of claiming features
in advance may stop what I suspect is a significant source of
contributions -- people who add features/patches for internal
Ron Mayer wrote:
We have not had that many cases where lack of
communication was a problem.
One could say too much communication was the problem this time.
I get the impression people implied they'd do something on a TODO
and didn't. Arguably the project had been better off if noone
had
[EMAIL PROTECTED] wrote:
Ron Mayer wrote:
We have not had that many cases where lack of
communication was a problem.
One could say too much communication was the problem this time.
I get the impression people implied they'd do something on a TODO
and didn't. Arguably the project had been
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Sat, Aug 05, 2006 at 12:19:54AM -0400, Matthew T. O'Connor wrote:
FTI is a biggie in my mind. I know it ain't happening for 8.2, but is
the general plan to integrate TSearch2 directly into the backend?
When the Tsearch
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Jim
C. Nasby) transmitted:
What say?
It's a shame to have a person burn cycles on this, but anything would be
an improvement over what we've got now.
Anything includes some options that would probably *not* be
Quoth [EMAIL PROTECTED] (David Fetter):
On Fri, Aug 04, 2006 at 02:37:56PM -0700, Neil Conway wrote:
On Fri, 2006-08-04 at 12:40 -0700, David Fetter wrote:
While I am not going to reopen the can of worms labeled 'bug
tracker', I think it would be good to have a little more formality
as far
+1
UPDATE/DELETE for CE are a big deal - I really wish we had INSERT too, then
we'd be able to claim complete support for partitioning, but this is a big
deal improvement.
- Luke
On 8/3/06 9:30 PM, Gavin Sherry [EMAIL PROTECTED] wrote:
A lot of the things on Tom's list are new bits of
On Fri, Aug 04, 2006 at 12:37:10AM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
To me new things are like PITR, Win32, savepoints, two-phase
commit, partitioned tables, tablespaces. These are from 8.0 and
8.1. What is there in 8.2 like that?
[ shrug... ] Five out of
Ühel kenal päeval, R, 2006-08-04 kell 00:46, kirjutas Bruce Momjian:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
To me new things are like PITR, Win32, savepoints, two-phase commit,
partitioned tables, tablespaces. These are from 8.0 and 8.1. What is
there in 8.2 like
David,
On 8/3/06 11:02 PM, David Fetter [EMAIL PROTECTED] wrote:
* Splitting queries among CPUs--possibly even among machines--for OLAP
loads
* In-place upgrades (pg_upgrade)
* Several varieties of replication, which I believe we as a project
will eventually endorse and ship
*
All,
grin Aren't I, the marketing geek, supposed to be the one whining about
this?
Seriously, PostgreSQL has the fastest release cycle of any RDBMS project in
the world. The request I'm hearing from large production users is to release
*less* often. So I don't find it a problem that this
David Fetter skrev:
As far as big missing features go, here's a short list:
* Windowing functions
If we are to wish for things the window functions and a proper
collation/locale support is what I miss the most.
/Dennis
---(end of
On Fri, Aug 04, 2006 at 08:27:02AM +0200, Dennis Bjorklund wrote:
If we are to wish for things the window functions and a proper
collation/locale support is what I miss the most.
Agreed. The complaints about collation/locale support have been
continuous over the years, and it really is quite
Bruce Momjian wrote:
Right, hence usability, not new enterprise features.
I'm not too happy about the label usability.
Ok, maybe postgres gets usable finally by supporting features that
MySQL had for a long time a MySql guy would say.
Regards,
Andreas
---(end
On 04/08/06, Andreas Pflug [EMAIL PROTECTED] wrote:
Bruce Momjian wrote:
Right, hence usability, not new enterprise features.
I'm not too happy about the label usability.
Ok, maybe postgres gets usable finally by supporting features that
MySQL had for a long time a MySql guy would say.
On 8/4/06, Luke Lonergan [EMAIL PROTECTED] wrote:
My ordering of this list in terms of priority is:
1) Windowing functions
2) MERGE
3) Index only access (new)
4) In-place upgrades
And what about compression of on-disk sorting? There has been a long
thread about this idea. Is there any news
Tom Lane wrote:
Not that there's anything wrong with a performance-oriented release
... but if you think that 8.2 is short on features, you'd better get
ready to be disappointed by every future release.
It's a pity that some expectations have been raised about features that
we haven't
101 - 200 of 289 matches
Mail list logo
