Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Joe Conway
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 entere

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Dennis Bjorklund
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 e

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Tom Lane
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

[HACKERS] Do we prefer software that works or software that looks good?

2004-04-23 Thread Shachar Shemesh
Tom Lane wrote: Personally I don't think that this is a "transitional issue" and we will someday all be happy in upper-case-only-land. 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 o

Re: [HACKERS] Current CVS tip segfaulting

2004-04-23 Thread Tom Lane
Alvaro Herrera Munoz <[EMAIL PROTECTED]> writes: > [ bug goes away if ] > ! dbname = argv[optind]; > [becomes] > ! dbname = pstrdup(argv[optind]); Hm, that's interesting. I could believe this would have something to do with overwriting the argv area, but we have not touched an

Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions

2004-04-23 Thread Tom Lane
"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > I don't agree with this, since mirrors are web mirrors ... but I do like > the 'Contrib' pointing to gborg/projects ... Yeah, I like the contrib link idea too. Much of the recent discussion comes down to gborg not being visible enough. However ...

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Dennis Bjorklund
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 conti

Re: [HACKERS] Current CVS tip segfaulting

2004-04-23 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > It could be a bug, but if it is, it is a different fix than the one I > did, I think. Re-reading Alvaro's message, I wondered if cranking logging up to a higher-than-default setting was needed to reproduce the bug. A quick experiment in that line didn't

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Tom Lane
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'

[HACKERS] The case for preserving case.

2004-04-23 Thread emf
Hello, postgresql hackers. I am working with a client with a 20k record MySQL database (that will shortly expand to 100k/1m) and a few thousand lines of PHP code that does a lot of DB interaction. Their application, with a lot of relationships between data and a bunch of data integrity require

Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions

2004-04-23 Thread Marc G. Fournier
On Thu, 22 Apr 2004 [EMAIL PROTECTED] wrote: > "Download - Mirrors - Lists - Users - Developers - Docs - Search" > > We could have: > > "Download - Docs - Lists - Search - Community - Contrib" > > "Download" would be a unified version of the Download/Mirrors links on the > current site. I don't a

Re: [HACKERS] Current CVS tip segfaulting

2004-04-23 Thread Bruce Momjian
FYI, I just tried: $ psql lkjasdf psql: FATAL: database "lkjasdf" does not exist (2) cat /u/pg/server.log LOG: database system was shut down at 2004-04-23 15:23:20 EDT LOG: checkpoint record is at 0/9D LOG: redo record is at 0/9D; undo r

Re: [HACKERS] Current CVS tip segfaulting

2004-04-23 Thread Bruce Momjian
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > In current (as of a couple hours ago) clean CVS tip sources, without any > > of my local changes, I'm getting a postmaster segfault when trying to > > connect to a non existant database. > > Hmm, works for me with this morning's sour

Re: [HACKERS] Current CVS tip segfaulting

2004-04-23 Thread Bruce Momjian
Alvaro Herrera Munoz wrote: > On Fri, Apr 23, 2004 at 07:00:05PM -0400, Bruce Momjian wrote: > > > > Please recompile with debug symbols and report back the stack trace. > > See the faq on running debug. > > No, I already did that (all my builds are like that anyway and I read > stack traces mor

Re: [HACKERS] Current CVS tip segfaulting

2004-04-23 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > In current (as of a couple hours ago) clean CVS tip sources, without any > of my local changes, I'm getting a postmaster segfault when trying to > connect to a non existant database. Hmm, works for me with this morning's sources. Bruce created a bug of

Re: [HACKERS] Current CVS tip segfaulting

2004-04-23 Thread Alvaro Herrera Munoz
On Fri, Apr 23, 2004 at 08:38:29PM -0400, Alvaro Herrera Munoz wrote: > On Fri, Apr 23, 2004 at 07:00:05PM -0400, Bruce Momjian wrote: > > > > Please recompile with debug symbols and report back the stack trace. > > See the faq on running debug. > > No, I already did that (all my builds are like

Re: [HACKERS] Current CVS tip segfaulting

2004-04-23 Thread Alvaro Herrera Munoz
On Fri, Apr 23, 2004 at 07:00:05PM -0400, Bruce Momjian wrote: > > Please recompile with debug symbols and report back the stack trace. > See the faq on running debug. No, I already did that (all my builds are like that anyway and I read stack traces more frequently than I'd like). The "can't r

Re: [HACKERS] Threading for 7.5

2004-04-23 Thread Bruce Momjian
I have completed most of the thread changes listed below. I have added automatic thread compile/link flag detection via configure from the URL listed below. I have kept per-platform customization that was used in the past. Please let me know of the new flag usage (like -pthread) makes your plat

Re: [HACKERS] Current CVS tip segfaulting

2004-04-23 Thread Bruce Momjian
Please recompile with debug symbols and report back the stack trace. See the faq on running debug. --- Alvaro Herrera wrote: > Hackers, > > In current (as of a couple hours ago) clean CVS tip sources, without any > of my

[HACKERS] Current CVS tip segfaulting

2004-04-23 Thread Alvaro Herrera
Hackers, In current (as of a couple hours ago) clean CVS tip sources, without any of my local changes, I'm getting a postmaster segfault when trying to connect to a non existant database. The generated core file does not seem to contain any useful information. The first time I saw this I managed

Re: [HACKERS] License question

2004-04-23 Thread Alvar Freude
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Shachar Shemesh <[EMAIL PROTECTED]> wrote: > The new requirement encapsulates the original requirement, and your > license is therefor not violated. I have, in fact, relicensed your work. no, the license is only for the *combined* work (which

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Alvar Freude
-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 imp

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Alvar Freude
-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 case

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Stephan Szabo
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 wi

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread pgsql
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 ourselve

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Stephan Szabo
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 > >stand

[HACKERS] pgFoundry delayed -- some setup issues

2004-04-23 Thread Josh Berkus
Folks, Well, as someone could have predicted, once we actually tried running some new projects on pgFoundry we ran into setup issues.We're resolving these and should have stuff up and running soon. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of br

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Jeff Davis
On Fri, 2004-04-23 at 07:13, Fabien COELHO wrote: > Yes. I really thing that it should be on by default, because those who > will need it more than others are those who will not know about tuning > configuration parameters. As I understand the requirements from > pg_autovacuum, it means that some

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Shachar Shemesh
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 ch

Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions

2004-04-23 Thread Andrew Sullivan
On Fri, Apr 23, 2004 at 01:05:40AM -0300, Marc G. Fournier wrote: > > This is all I'm saying ... its like when we packaged up our first eRServer > ... I didn't require our clients to go out and download PostgreSQL to > build it, I pulled in the few files from our build environment into the > packa

Re: [HACKERS] [pgsql-advocacy] What can we learn from MySQL?

2004-04-23 Thread Jim C. Nasby
On Fri, Apr 23, 2004 at 02:35:48PM +0800, Christopher Kings-Lynne 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. > > > >Questions I have are: > > I have already told Bruce at length about the single most

Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions

2004-04-23 Thread jearl
Rod Taylor <[EMAIL PROTECTED]> writes: >> The difference is that a "better" admin tool is very subjective where as >> a buffer strategy is not... or maybe the difference is really that >> everyone thinks they are qualified to pick a "better" admin tool, but >> very few can really argue as to a bet

Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions

2004-04-23 Thread Matthew T. O'Connor
>> On Thu, 2004-04-22 at 23:05, Robert Treat wrote: > The difference is that a "better" admin tool is very subjective where as > a buffer strategy is not... or maybe the difference is really that > everyone thinks they are qualified to pick a "better" admin tool, but > very few can really argue as

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Merlin Moncure
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 emine

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Robert Treat
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 fo

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread J. Andrew Rogers
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 growt

Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions

2004-04-23 Thread Rod Taylor
> The difference is that a "better" admin tool is very subjective where as > a buffer strategy is not... or maybe the difference is really that > everyone thinks they are qualified to pick a "better" admin tool, but > very few can really argue as to a better buffer strategy. While I think > your cr

Re: [HACKERS] PITR, nested transactions, tablespaces, 2-phase commit:

2004-04-23 Thread Bob . Henkel
Just so you know I'm very thankful for your hard work and I'm sure many of us are. I have been waiting for this kind of functionally in Postgresql! |-+--> | | Heikki Linnakangas | | | <[EMAIL PROTECTED]> |

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Andrew Dunstan
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 use

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Robert Treat
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 folde

Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions

2004-04-23 Thread Robert Treat
On Fri, 2004-04-23 at 11:02, Rod Taylor wrote: > On Thu, 2004-04-22 at 23:05, Robert Treat wrote: > > On Thursday 22 April 2004 13:55, Barry Lind wrote: > > > I think the solution lies in improving www.postgresql.org. At the end > > > of the day it doesn't matter where source code lives, what matt

Re: [HACKERS] PITR, nested transactions, tablespaces, 2-phase commit: Status

2004-04-23 Thread Heikki Linnakangas
On Sat, 17 Apr 2004, Bruce Momjian wrote: > Would folks report on the current status of these projects: > > o nested transactions (Alvaro Herrera) > o tablespaces (Gavin Sherry) > o PITR (Simon Riggs) > o 2-phase commit (Heikki Linnakangas) I've been very busy with at work

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread D'Arcy J.M. Cain
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

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Bruce Momjian
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. >

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Andrew Dunstan
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 h

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Matthew T. O'Connor
> 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 po

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Matthew T. O'Connor
> 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 envisi

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread D'Arcy J.M. Cain
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 pg_

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Stephan Szabo
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 > > > s

Re: [HACKERS] [pgsql-advocacy] What can we learn from MySQL?

2004-04-23 Thread scott.marlowe
On Fri, 23 Apr 2004, 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/22292

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Dave Cramer
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

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Bruce Momjian
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 > > Ma

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Robert Treat
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 client

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Matthew T. O'Connor
>> 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

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Thomas Swan
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

Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions

2004-04-23 Thread Rod Taylor
On Thu, 2004-04-22 at 23:05, Robert Treat wrote: > On Thursday 22 April 2004 13:55, Barry Lind wrote: > > I think the solution lies in improving www.postgresql.org. At the end > > of the day it doesn't matter where source code lives, what matters is > > can people find what they are expecting. Gi

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Fabien COELHO
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

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Matthew T. O'Connor
> 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 > datab

Re: [HACKERS] [pgsql-advocacy] What can we learn from MySQL?

2004-04-23 Thread Peter Eisentraut
Am Freitag, 23. April 2004 06:09 schrieb Bruce Momjian: > o Are we marketing ourselves properly? > o Are we focused enough on ease-of-use issues? > o How do we position ourselves against a database that some > say is "good enough" (MySQL), and another one that some >

Re: [HACKERS] [pgsql-advocacy] What can we learn from MySQL?

2004-04-23 Thread Bruce Momjian
Christopher Kings-Lynne 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. > > > > Questions I have are: > > I have already told Bruce at length about the single most common > complaint in the phpPgAdmin

Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions

2004-04-23 Thread Fabien COELHO
> > The specific details aren't especially relevant to this thread, though. > > What is relevant is that we agree to a commitment that we will make > > it easy to build modules outside the current Postgres build environment, > > and that we will have an ongoing commitment to make sure that that ke

Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions

2004-04-23 Thread Jan Wieck
Tom Lane wrote: The specific details aren't especially relevant to this thread, though. What is relevant is that we agree to a commitment that we will make it easy to build modules outside the current Postgres build environment, and that we will have an ongoing commitment to make sure that that ke

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Tom Lane
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

Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions

2004-04-23 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > There's more than one issue. CPAN makes it easy for end users to find > and install little projects. One thing I would like to see is a more direct link to the drivers (e.g. DBD::Pg, JDBC) from the download page. I don't think they need to liv

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Hans-Jürgen Schönig
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

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Dennis Bjorklund
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 someth

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Karel Zak
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

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Fabien COELHO
> 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

Re: [HACKERS] What can we learn from MySQL?

2004-04-23 Thread Shachar Shemesh
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/2229212&mode=nested&tid=137&tid=185&tid=187&tid=198 My