Robert Treat wrote:
On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote:
You know, that's kind of the point of all things related to MySQL.
It's better than nothing. PostgreSQL doesn't do things because it's
better than nothing. snip
(Same as how MySQL guesses the result of a modulo
On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote:
You know, that's kind of the point of all things related to MySQL.
It's better than nothing. PostgreSQL doesn't do things because it's
better than nothing. snip
(Same as how MySQL guesses the result of a modulo operation, and gets it
On Tue, May 04, 2004 at 03:06:53PM -0400, Robert Treat wrote:
On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote:
You know, that's kind of the point of all things related to MySQL.
It's better than nothing. PostgreSQL doesn't do things because it's
better than nothing. snip
(Same as
Robert Treat [EMAIL PROTECTED] writes:
On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote:
You know, that's kind of the point of all things related to MySQL.
It's better than nothing. PostgreSQL doesn't do things because
it's better than nothing. snip (Same as how MySQL guesses the
Hi!
Tim Conrad wrote:
I was researching an article I wrote about a comparison between
Postgres and MySQL recently (If you want, you can read the article
at http://www.devx.com/dbzone/Article/20743/). I noticed some clear
differences between the mysql.com website and the Postgres website.
Sorry,
Alexey Borzov wrote:
I realize this. I also realize that having a nicely defined roadmap
would
give Postgres a hands up in this category.
A hands up in *what* category? In bragging?
In telling your boss, I think we should use Postgresql.
It's likely he's not stupid, and it's reasonable for him
Hi!
Tim Conrad wrote:
My favourite part of it is:
MySQL uses traditional row-level locking. PostgreSQL uses something
called Multi Version Concurrency Control (MVCC) by default. MVCC is a
little different from row-level locking in that transactions on the
database are performed on a
Dear Tim,
These are execellent proposals. My only remark would be to build a
step-by-step approach.
In a first stage, we could set-up a minimal web page for the Win32 port:
- PostgreSQL Win32 installer (possibly translated),
- translation of the web page in 40 languages,
- step-by-step
On Mon, Apr 26, 2004 at 04:41:35PM -0400, Bruce Momjian wrote:
Jean-Michel POURE wrote:
[ PGP not available, raw data follows ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My question is, What can we learn from MySQL? I don't know there is
anything, but I think it makes sense to
I've been sort-of reading this thread off and on, so this may
contain duplicate suggestions.
I was researching an article I wrote about a comparison between
Postgres and MySQL recently (If you want, you can read the article
at http://www.devx.com/dbzone/Article/20743/). I noticed some clear
On Tue, 27 Apr 2004, Tim Conrad wrote:
2) There doesn't seem to be a clear roadmap on Postgres features.
When certian things are expected. There's the TODO list that
Bruce maintains, but it only outlines 'near' fixes. MySQL has a
nice listing of what to expect in certian future
On Tue, Apr 27, 2004 at 07:55:08PM +0400, Alexey Borzov wrote:
Hi!
Tim Conrad wrote:
I was researching an article I wrote about a comparison between
Postgres and MySQL recently (If you want, you can read the article
at http://www.devx.com/dbzone/Article/20743/). I noticed some clear
On Tue, Apr 27, 2004 at 12:58:59PM -0300, Marc G. Fournier wrote:
On Tue, 27 Apr 2004, Tim Conrad wrote:
2) There doesn't seem to be a clear roadmap on Postgres features.
When certian things are expected. There's the TODO list that
Bruce maintains, but it only outlines 'near' fixes.
Tim Conrad wrote:
Of course, some gullible people actually believe this and compare [2]
the existing and working implementations with vaporware (MySQL 5.1,
anyone?).
On those same lines, there doesn't seem to be anything about the
improvements in the minor versions. It seems
On Tue, 27 Apr 2004, Tim Conrad wrote:
On Tue, Apr 27, 2004 at 12:58:59PM -0300, Marc G. Fournier wrote:
On Tue, 27 Apr 2004, Tim Conrad wrote:
2) There doesn't seem to be a clear roadmap on Postgres features.
When certian things are expected. There's the TODO list that
Bruce
Not entirely true. I've read enough on the lists to see Bruce or
others saying 'x feature isn't expected until version y.z'. Heck, to
me, something that says 'we're hoping for feature x in version y.z',
but it's not an exact science. See the MySQL releases as an example
:)
Ah, then
On Tue, Apr 27, 2004 at 12:57:46PM -0400, Tim Conrad wrote:
Seriously, though. I was looking through the list yesterday trying
to figure out something, and it was kind of hard to do.But, more to
my point, this stuff is in the MySQL manual, making it easy to find.
(Yes. I know what MySQL
Alexey Borzov wrote:
Hi!
Tim Conrad wrote:
My favourite part of it is:
MySQL uses traditional row-level locking. PostgreSQL uses something
called Multi Version Concurrency Control (MVCC) by default. MVCC is
a little different from row-level locking in that transactions on
the database
Bruce Momjian wrote:
Peter Eisentraut wrote:
Rob wrote:
But I think there is room to go further, I don't see any reason why
that default install can't include example DBs,
One reason is that a useful example database would likely have a
download footprint of 10 MB or more. Having this in the
Bruno Wolff III wrote:
On Fri, Apr 23, 2004 at 16:36:57 -0400,
[EMAIL PROTECTED] wrote:
Ease of use is VERY important, but few suggestions that address this are
ever really accepted. Yes, focusing on the functionality is the primary
concern, but how you set it up and deploy it is VERY important.
Bruno Wolff III wrote:
On Fri, Apr 23, 2004 at 16:36:57 -0400,
[EMAIL PROTECTED] wrote:
Ease of use is VERY important, but few suggestions that address this are
ever really accepted. Yes, focusing on the functionality is the primary
concern, but how you set it up and deploy it is VERY
I'm certain you guys could do a far better installer than the one Oracle
has, which is very, very fragile. There's all kinds of wonkiness to try
and get it to work on a non-supported linux distro (gentoo in my case),
and from talking to people who've dealt with it on redhat it's no
better.
Also,
Jean-Michel POURE wrote:
[ PGP not available, raw data follows ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My question is, What can we learn from MySQL? I don't know there is
anything, but I think it makes sense to ask the question.
Dear Bruce,
Taking the example of pgAdmin III,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My question is, What can we learn from MySQL? I don't know there is
anything, but I think it makes sense to ask the question.
Dear Bruce,
Taking the example of pgAdmin III, which reached nearly one million hits in
December
Rob wrote:
But I think there is room to go further, I don't see any reason why
that default install can't include example DBs,
One reason is that a useful example database would likely have a
download footprint of 10 MB or more. Having this in the default
download would not be appreciated by
Peter Eisentraut wrote:
Rob wrote:
But I think there is room to go further, I don't see any reason why
that default install can't include example DBs,
One reason is that a useful example database would likely have a
download footprint of 10 MB or more. Having this in the default
Tom Lane wrote:
Aside from the reality that apps aren't very consistent about their
quoting behavior, the fly in this ointment is that whenever you query
the database catalogs you will see the stored spelling of the name.
So apps that rely on seeing the same spelling in the catalog that they
On Fri, Apr 23, 2004 at 10:56:43PM -0700, Joe Conway wrote:
Tom Lane wrote:
Aside from the reality that apps aren't very consistent about their
quoting behavior, the fly in this ointment is that whenever you query
the database catalogs you will see the stored spelling of the name.
So apps
On Fri, Apr 23, 2004 at 16:36:57 -0400,
[EMAIL PROTECTED] wrote:
Ease of use is VERY important, but few suggestions that address this are
ever really accepted. Yes, focusing on the functionality is the primary
concern, but how you set it up and deploy it is VERY important. You guys
need to
On Fri, Apr 23, 2004 at 11:45:28AM -0400, Robert Treat wrote:
lower will now simply be folder upper. the only people who will have a
problem are those who quote on one end but not the other, which is bad
practice anyways... so i would say if your serious about it, make the
patch as GUC
I think that when considering install, it is very
important, if not critical, that we all understand who
is doing the install. Certainly if it is a person
much like us, meaning people on the
hackers/development list, we can all handle more terse
installs. Personally, I like the freedom of
Bruce Momjian wrote:
My question is, What can we learn from MySQL? I don't know there is
anything, but I think it makes sense to ask the question.
MySQL was my first introduction to SQL databases (I had dabbled with
Clipper and Foxpro years earlier, but only for a couple of months and
had
Bruce Momjian wrote:
Here is a blog about a recent MySQL conference with title, Why MySQL
Grew So Fast:
http://www.oreillynet.com/pub/wlg/4715
and a a Slashdot discussion about it:
http://developers.slashdot.org/article.pl?sid=04/04/20/2229212mode=nestedtid=137tid=185tid=187tid=198
My
My question is, What can we learn from MySQL? I don't know there is
anything, but I think it makes sense to ask the question.
Questions I have are:
o Are we focused enough on ease-of-use issues?
There are two issues here : ease-of-use for admin and basic users.
I recognize my
On Fri, Apr 23, 2004 at 01:05:21PM +0700, David Garamond wrote:
So in my opinion, as long as the general awareness about RDBMS (on what
tasks/responsibilities it should do, what features it generally has to
have, etc) is low, people will be looking at MySQL as good enough and
will not be
On Fri, 23 Apr 2004, Shachar Shemesh wrote:
When I ask about non-standard complience of Pg (turning unquoted
identifiers to lowercase instead of uppercase, violating the SQL
standard, and requring an expensive rewrite of clients), and I get the
answer uppercase is ugly, I think something
Karel Zak wrote:
On Fri, Apr 23, 2004 at 01:05:21PM +0700, David Garamond wrote:
So in my opinion, as long as the general awareness about RDBMS (on what
tasks/responsibilities it should do, what features it generally has to
have, etc) is low, people will be looking at MySQL as good enough and
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Fri, 23 Apr 2004, Shachar Shemesh wrote:
When I ask about non-standard complience of Pg (turning unquoted
identifiers to lowercase instead of uppercase, violating the SQL
standard, and requring an expensive rewrite of clients), and I get the
There are two issues here : ease-of-use for admin and basic users.
On for former point, admin ease-of-use, A little story a few month ago.
I succeeded in advising production people here to switch some applications
from a mysql database, which was working perfectly, to a postgres
database. A
Dear Matthew,
My goal is to have pg_autovacuum integrated into the backend for 7.5.
I know about that, and that would be a good thing.
I don't know if it will default to being turned on or off, I'm sure that
will be a discussion, but if it is defaulted to on, then this whole
problem of
Bruce Momjian wrote:
My question is, What can we learn from MySQL? I don't know there is
anything, but I think it makes sense to ask the question.
MySQL became popular at my university when the students discovered they
could install it on their personal computers. Just the exposure for
My goal is to have pg_autovacuum integrated into the backend for 7.5.
I know about that, and that would be a good thing.
I hope so!
I don't know if it will default to being turned on or off, I'm sure that
will be a discussion, but if it is defaulted to on, then this whole
problem of having
On Fri, 2004-04-23 at 05:22, Dennis Bjorklund wrote:
On Fri, 23 Apr 2004, Shachar Shemesh wrote:
When I ask about non-standard complience of Pg (turning unquoted
identifiers to lowercase instead of uppercase, violating the SQL
standard, and requring an expensive rewrite of clients), and
Matthew T. O'Connor wrote:
I think it's premature to have this conversation. I need to get something
done / working before we dicuss optimal configuration. That said, I also
agree that if it's good enough, it should be on by default.
Good luck;-)
Thanks, I'll need it
Matthew
Does the current implementation of pg_autovacuum have a way of setting
windows where it is allowed to vacuum? Many large 24/7 will only allow
vacuumming at certain times of the day.
Dave
On Fri, 2004-04-23 at 08:58, Matthew T. O'Connor wrote:
There are two issues here : ease-of-use for admin
On Fri, 23 Apr 2004, Robert Treat wrote:
On Fri, 2004-04-23 at 05:22, Dennis Bjorklund wrote:
On Fri, 23 Apr 2004, Shachar Shemesh wrote:
When I ask about non-standard complience of Pg (turning unquoted
identifiers to lowercase instead of uppercase, violating the SQL
standard, and
On Fri, 23 Apr 2004 11:07:20 -0400
Dave Cramer [EMAIL PROTECTED] wrote:
Does the current implementation of pg_autovacuum have a way of setting
windows where it is allowed to vacuum? Many large 24/7 will only allow
vacuumming at certain times of the day.
It seems to me that the point of
Does the current implementation of pg_autovacuum have a way of setting
windows where it is allowed to vacuum? Many large 24/7 will only allow
vacuumming at certain times of the day.
No the current implementation doesn't, but such a feature is in the works
(planned anyway). What I was
On Fri, 23 Apr 2004 11:07:20 -0400
Dave Cramer [EMAIL PROTECTED] wrote:
Does the current implementation of pg_autovacuum have a way of setting
windows where it is allowed to vacuum? Many large 24/7 will only allow
vacuumming at certain times of the day.
It seems to me that the point of
Stephan Szabo wrote:
I know this to be true, but don't fully understand it... if our default
behavior is to fold lower, and we change it to just fold upper... then
in theory this shouldn't break anything since what used to be folder
lower will now simply be folder upper. the only people who will
D'Arcy J.M. Cain wrote:
On Fri, 23 Apr 2004 11:07:20 -0400
Dave Cramer [EMAIL PROTECTED] wrote:
Does the current implementation of pg_autovacuum have a way of setting
windows where it is allowed to vacuum? Many large 24/7 will only allow
vacuumming at certain times of the day.
It seems
On Fri, 23 Apr 2004 13:08:30 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
D'Arcy J.M. Cain wrote:
It seems to me that the point of pg_autovacuum would be to run 24/7
so that there is never big hit on the system. Perhaps it could be
designed to throttle itself based on current system
On Fri, 2004-04-23 at 13:11, Andrew Dunstan wrote:
Stephan Szabo wrote:
I know this to be true, but don't fully understand it... if our default
behavior is to fold lower, and we change it to just fold upper... then
in theory this shouldn't break anything since what used to be folder
lower
Robert Treat wrote:
On Fri, 2004-04-23 at 13:11, Andrew Dunstan wrote:
Stephan Szabo wrote:
I know this to be true, but don't fully understand it... if our default
behavior is to fold lower, and we change it to just fold upper... then
in theory this shouldn't break anything since what
On Thu, 2004-04-22 at 21:09, Bruce Momjian wrote:
Questions I have are:
o Are we marketing ourselves properly?
It is perhaps less a matter of marketing and more a matter of
word-of-mouth mind share. I don't see much evidence of effective direct
marketing, but I've noticed a huge growth
On Fri, 2004-04-23 at 14:28, Andrew Dunstan wrote:
Robert Treat wrote:
of course you could just create duplicates of all
the functions in both upper and lower case, that way whichever way you
fold it matches :-)
That strikes me as an instant recipe for shooting yourself in the foot,
as
J. Andrew Rogers wrote:
No. The greatest strength of Postgres, marketing-wise, are technical
and is what drives its growth today. I think most of the ease-of-use
issues are in the packaging of the larger Postgres product and
mid-level
developer documentation, both of which seem to be
Stephan Szabo wrote:
I've tried just changing the parser to unconditionally casefold to upper.
First thing that happens is that initdb breaks. In addition, you have
potential issues with comparisons against the catalog's versions of
standard functions as such if you allow the case folding to be
On Fri, 23 Apr 2004, Shachar Shemesh wrote:
Stephan Szabo wrote:
I've tried just changing the parser to unconditionally casefold to upper.
First thing that happens is that initdb breaks. In addition, you have
potential issues with comparisons against the catalog's versions of
standard
I have been thinking about this subject for a LONG time, and I hope I have
something to contribute.
My question is, What can we learn from MySQL? I don't know there is
anything, but I think it makes sense to ask the question.
Questions I have are:
o Are we marketing ourselves
On Fri, 23 Apr 2004, Stephan Szabo wrote:
On Fri, 23 Apr 2004, Shachar Shemesh wrote:
Stephan Szabo wrote:
I've tried just changing the parser to unconditionally casefold to upper.
First thing that happens is that initdb breaks. In addition, you have
potential issues with comparisons
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
- -- Bruce Momjian [EMAIL PROTECTED] wrote:
o Are we marketing ourselves properly?
while talking about MySQL, there is the myth, that MySQL is fast; and that
because MyISAM has no transactions, that it is faster.
That is in most cases
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
- -- [EMAIL PROTECTED] wrote:
I would say this is a clear 'NO!' When ever I read about open-source being
used anywhere, I always read MySQL. They are *very* good at this.
yes!
Some days ago, there was a news in the Heise Newsticker (most
Stephan Szabo [EMAIL PROTECTED] writes:
To clarify, I'm thinking about things where an application had gotten a
quoted name and is now trying to use it where the object's canonical name
was changed due to quoting changes. This only happens when quoting
is inconsistently applied, but that's
On Sat, 24 Apr 2004, Tom Lane wrote:
Upper-case-only sucks, by every known measure of readability, and I
don't want to have to put up with a database that forces that
1960s-vintage-hardware mindset on me.
Well, get used to it :-)
So what I'm holding out for is a design that lets me continue
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Sat, 24 Apr 2004, Tom Lane wrote:
So what I'm holding out for is a design that lets me continue to see the
current behavior if I set a GUC variable that says that's what I want.
Wouldn't the upper case identifiers just be visible in the \d output,
On Sat, 24 Apr 2004, Tom Lane wrote:
First I thought that one can store the string with case all the time, and
just convert when needed (when comparing identifiers).
People keep suggesting these random not-quite-standard behaviors, but
I fail to see the point. Are you arguing for exact
Here is a blog about a recent MySQL conference with title, Why MySQL
Grew So Fast:
http://www.oreillynet.com/pub/wlg/4715
and a a Slashdot discussion about it:
http://developers.slashdot.org/article.pl?sid=04/04/20/2229212mode=nestedtid=137tid=185tid=187tid=198
My question is,
68 matches
Mail list logo
