Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Ühel kenal päeval, R, 2006-05-19 kell 11:29, kirjutas Mark Woodward: > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > >> Mark Woodward wrote: > >>> Again, there is so much code for MySQL, a MySQL emulation layer, MEL > >>> for > >>> short, could allow plug and play compatibility for open source, and > >>> closed > >>> source, applications that otherwise would force a PostgreSQL user to > >>> hold > >>> his or her nose and use MySQL. > >>> > >> If we had infinite resources this might make sense. We don't, so it > >> doesn't. There is a real cost to producing a compatibility layer, and > >> the cost will be those spiffy new features. > > > > The real problem is that there's a whole lot of stuff, such as mysql's > > weak error checking, that I don't think a "compatibility layer" could > > sanely provide. > > > I kind of agree with this statement, but while I was playing devils's > advocate and just grousing a bit about having to use MySQL, there is a > sort of reality of "openomics" where mind-share is everything. Maybe we could have a Google SoC project to strip Postgres of all its useful features (mainly ACID, but also introduce NULL==""==0 and weak foreign keys) to make it MySQL compatible. And if we start locking a table on each update, we can get rid of MVCC altogether and do fast selects, in-place updates and select from indexes only. Then that branch (PostgreSQLite) could be pimped to MySQL users as a way to "support" postgres. Nah, not really useful, but perhaps we could publicize the list of things that would have to go to be compatible :P Hannu ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
> On Fri, May 19, 2006 at 07:04:47PM -0400, Bruce Momjian wrote: >> > libreadline is not a problem because you can distribute postgresql >> > compiled with readline and comply with all licences involved >> > simultaneously. It doesn't work with openssl because the licence >> > requires things that are incompatable with the GPL. >> >> My question is whether psql using libreadline.so has to be GPL, meaning >> the psql source has to be included in a binary distribution. > > IANAL, but yes. Or any other of the methods allowed, like providing a > written voucher valid for at least three years. People who feel they > need to keep the source to psql secret should link against libeditline > instead. > > The way I understand it, the GPL affects programs in two main ways: > > 1. A program which is GPL'd must, when distributed, be able to provide > all source used to build it under terms compatable with the GPL. This is not technically true. If you incorporate GPL code that is publically available and unchanged, you needn't provide the 3rd party packages. > > 2. A program which includes a GPL'd header file while building, must, > when distributed, provide its own source and the library under GPL > compatable terms, but not necessariliy the source of anything else > needed to build it. This is why it's OK that psql links against openssl > and readline. This is sort of a disputable position, and RMS himself isn't clear. If the header files are simply definitions and declarations, then no GPL material is actually included in a binary. However, inline functions and macros may constitute code. > > These are obviously only relevent when distributing precompiled > binaries. If you are only distributing source, none of the above > applies to you. > Of course. > There's a third method that some people claim, but I don't buy. This > where a program using an interface of a GPL'd library somehow become a > derived work of said library. That's just way whacked out. There is no supporting argument for that, however, RMS supporting writings indicate that he defines "derived" as being in the same process space. > > You may ofcourse disagree with any of the above, and hey, if you have a > lawyer to back you up, who am I to argue? I have talked to too many lawyers, sigh, aout this stuff. > > As for why you don't solve the problem by distributing a libpq not > compiled against OpenSSL, well, that's a different question. Back when > SSL was considered an arms exports by the US, having both SSL and > non-SSL versions was common (and a big PITA). When that disappeared, > the main reason for the split went away and people started compiling > SSL by default. This solved the problem for 99% of programs. > > However, one tiny subset remains problematic: > - A library implements SSL, but only using OpenSSL > - The library doesn't use the GPL, or doesn't have an OpenSSL exception > clause. > - A GPL'd program uses this library, without an OpenSSL exception > clause. > > In this subset of a subset of a subset of programs, it's a problem. > Many libraries that implement SSL provide an alternative to OpenSSL, > many programs using such libraries have exception clauses so that > there's just a handful of programs and libraries that are problematic. > > As long as there's a possibility that the situation can change (either > every GPL program using postgresql gains an exception clause, or > postgresql might someday support some other library) it will probably > stay this way. > > If the the postgresql core decides that OpenSSL will be the only SSL > ever supported, no matter what, well, the split distribution may yet > happen. In the meantime, we have status quo. > > Have a nice day, > -- > Martijn van Oosterhout http://svana.org/kleptog/ >> From each according to his ability. To each according to his ability to >> litigate. > ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Then again PGfoundry is great to keep development centered, but finding and building a new package is not really a one-liner, and if you're unlucky you might get alpha-quality code installed. :) Mammoth PostgreSQL was designed to fill this role. It is an FOSS project (www.mammothpostgresql.org) that is designed to be a COMPLETE postgresql distribution. Joshua D. Drake ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Sat, May 20, 2006 at 10:36:25AM +0200, Lukas Smith wrote: > Hi, > > I really think that PostgreSQL could benefit from a packaged solution > that incorporates a lot of the contrib stuff (tsearch2, maybe even some > replication setups ..). I really like the approach that PostgreSQL is a > clean yet highly extensible base from which other people can build their > specific tools. I think we're starting to see some of that, with things like the live CD. What I'd rather see time spent on is a framework that makes it easier to grab things from pgFoundry. To use a bad example, think CPAN for PostgreSQL. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Fri, May 19, 2006 at 06:01:19PM -0400, Jonah H. Harris wrote: > On 5/19/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote: > >And with that, I am going to sit in a lawn chair and watch the bonfire. > > This is one of the finest examples of unfocused discussions I've ever > seen on -hackers... while surely entertaining, what a huge waste of > time. I tried a few times to move it to -advococy... -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
> > My question is whether psql using libreadline.so has to be GPL, meaning > the psql source has to be included in a binary distribution. If I understand what I have been told by lawyers, here's what using a GPL, and NOT LGPL, library means: According to RMS, the definition of a derivitive work is one which shares the same address space when running. The in-memory process separation also separates works. One may argue this definition, but it is in supporting documents to the GPL and likely to be considered as the intention of the GPL in a court of law. There is no requirement of shipping source with a binary. One must "make available" the source. This can be done by a web site or alternate CD distribution. It need not be free, as in beer, but must be free of any restrictions beyond those of the GPL. There is no requirement that one would need to make the source of the 3rd party GPL library available, as it is available from the original source from whence it was obtained in the first place. Any changes, however, made, by you, to that library must be made available. (If you do not make modifications to libreadline, you don't even need to worry about it.) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On 5/20/06, Lukas Smith <[EMAIL PROTECTED]> wrote: The improvements to the installer are great, but there simply needs to be a packaged solution that adds more of the things people are very likely to use. From my understanding Bizgres goes in that direction? I just think that whatever highly packaged solution PostgreSQL picks, this should be the download that is pushed at conferences, in articles and books. People with a clue will still know where they can get the clean base. Hmm, a Comprehensive PostgreSQL Archive Network? ;) I mean, something like CPAN, CTAN or CRAN? :) I mean, the -contrib is great, but pushing other things there is a bit tricky (to say the least) from the maintenance point of view. (Every bugfix, a new release of -contrib, etc, etc...). Then again PGfoundry is great to keep development centered, but finding and building a new package is not really a one-liner, and if you're unlucky you might get alpha-quality code installed. :) I think a CPgAN-like solution would be the best. A uniform method of getting approved Pg extensions. It would simplify installing the extensions, and would encourage distributions to package such extensions. Somebody suggested apt-get install postgresql-contrib. Imagine: apt-get install postgresql-datatype-fqdn apt-get install postgresql-gist-ltree ...and so on. Regards, Dawid ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Lukas Kahwe Smith wrote: ... >> apt-get install postgresql-8.1 postgresql-contrib-8.1 >> >> Voila! Tsearch installed at your fingertips. What else were you >> expecting? > > I expect this to be one package and I expect this to be what is pushed > as the default package on all platforms. If someone just sat in an pgsql > talk (or even a talk that mentions pgsql), has read an article, picked > up a book .. this is what he should be downloading and installing. ... > If PostgreSQL pushes FooSQL as its "packaged solution" at all > opportunities I am sure it would quickly get into the heads of people > and if done in a concerted effort along with the corporate sponsors it > could provide for a huge marketing opportunity and a slew of articles > from the press. But that is a topic for another list. > maybe the package should read: postgresql-heavy postgresql-complete or even as you seem to suggest: postgresql where the other parts are postgresql-clients, postgresql-server postgresql-contrib and so on. Beware, however, if "complete" means with gui clients, not all people would be happy if you pull X and friends to their unix servers :-) So whatever is in "complete" should depend on the target platform. I think the naming schema of the debian packages go in the right direction - maybe this can be harmonized along the distributions? Regards Tino Wildenhain ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Martijn van Oosterhout wrote: On Sat, May 20, 2006 at 10:36:25AM +0200, Lukas Smith wrote: The improvements to the installer are great, but there simply needs to be a packaged solution that adds more of the things people are very likely to use. From my understanding Bizgres goes in that direction? I just think that whatever highly packaged solution PostgreSQL picks, this should be the download that is pushed at conferences, in articles and books. People with a clue will still know where they can get the clean base. There is a fantastic packaged solution already: apt-get install postgresql-8.1 postgresql-contrib-8.1 Voila! Tsearch installed at your fingertips. What else were you expecting? I expect this to be one package and I expect this to be what is pushed as the default package on all platforms. If someone just sat in an pgsql talk (or even a talk that mentions pgsql), has read an article, picked up a book .. this is what he should be downloading and installing. I do think that the name PostgreSQL has a fair amount of mindshare, but I do not think that this package needs to be called PostgreSQL necessarily. The problem with calling it PostgreSQL is that this would mean moving things into the core distribution which do not belong there. But expecting the unwashed masses to understand that they need to install contrib ontop of PostgreSQL is not a good idea. If PostgreSQL pushes FooSQL as its "packaged solution" at all opportunities I am sure it would quickly get into the heads of people and if done in a concerted effort along with the corporate sponsors it could provide for a huge marketing opportunity and a slew of articles from the press. But that is a topic for another list. regards, Lukas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Sat, May 20, 2006 at 10:36:25AM +0200, Lukas Smith wrote: > The improvements to the installer are great, but there simply needs to > be a packaged solution that adds more of the things people are very > likely to use. From my understanding Bizgres goes in that direction? I > just think that whatever highly packaged solution PostgreSQL picks, this > should be the download that is pushed at conferences, in articles and > books. People with a clue will still know where they can get the clean base. There is a fantastic packaged solution already: apt-get install postgresql-8.1 postgresql-contrib-8.1 Voila! Tsearch installed at your fingertips. What else were you expecting? Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Hi, I really think that PostgreSQL could benefit from a packaged solution that incorporates a lot of the contrib stuff (tsearch2, maybe even some replication setups ..). I really like the approach that PostgreSQL is a clean yet highly extensible base from which other people can build their specific tools. However the fact of the matter is that MySQL provides a good enough, yet very easy to setup and do semi advanced things (like full text, replication etc). My key point here is _good enough_. This means there is obviously still an opportunity to give them something _better_, as long as it does not get in their way of being easy to setup. The improvements to the installer are great, but there simply needs to be a packaged solution that adds more of the things people are very likely to use. From my understanding Bizgres goes in that direction? I just think that whatever highly packaged solution PostgreSQL picks, this should be the download that is pushed at conferences, in articles and books. People with a clue will still know where they can get the clean base. regards, Lukas ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Fri, May 19, 2006 at 07:04:47PM -0400, Bruce Momjian wrote: > > libreadline is not a problem because you can distribute postgresql > > compiled with readline and comply with all licences involved > > simultaneously. It doesn't work with openssl because the licence > > requires things that are incompatable with the GPL. > > My question is whether psql using libreadline.so has to be GPL, meaning > the psql source has to be included in a binary distribution. IANAL, but yes. Or any other of the methods allowed, like providing a written voucher valid for at least three years. People who feel they need to keep the source to psql secret should link against libeditline instead. The way I understand it, the GPL affects programs in two main ways: 1. A program which is GPL'd must, when distributed, be able to provide all source used to build it under terms compatable with the GPL. 2. A program which includes a GPL'd header file while building, must, when distributed, provide its own source and the library under GPL compatable terms, but not necessariliy the source of anything else needed to build it. This is why it's OK that psql links against openssl and readline. These are obviously only relevent when distributing precompiled binaries. If you are only distributing source, none of the above applies to you. There's a third method that some people claim, but I don't buy. This where a program using an interface of a GPL'd library somehow become a derived work of said library. That's just way whacked out. You may ofcourse disagree with any of the above, and hey, if you have a lawyer to back you up, who am I to argue? As for why you don't solve the problem by distributing a libpq not compiled against OpenSSL, well, that's a different question. Back when SSL was considered an arms exports by the US, having both SSL and non-SSL versions was common (and a big PITA). When that disappeared, the main reason for the split went away and people started compiling SSL by default. This solved the problem for 99% of programs. However, one tiny subset remains problematic: - A library implements SSL, but only using OpenSSL - The library doesn't use the GPL, or doesn't have an OpenSSL exception clause. - A GPL'd program uses this library, without an OpenSSL exception clause. In this subset of a subset of a subset of programs, it's a problem. Many libraries that implement SSL provide an alternative to OpenSSL, many programs using such libraries have exception clauses so that there's just a handful of programs and libraries that are problematic. As long as there's a possibility that the situation can change (either every GPL program using postgresql gains an exception clause, or postgresql might someday support some other library) it will probably stay this way. If the the postgresql core decides that OpenSSL will be the only SSL ever supported, no matter what, well, the split distribution may yet happen. In the meantime, we have status quo. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Joshua D. Drake wrote: > Jonah H. Harris wrote: > > On 5/19/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote: > >> And with that, I am going to sit in a lawn chair and watch the bonfire. > > > > This is one of the finest examples of unfocused discussions I've ever > > seen on -hackers... while surely entertaining, what a huge waste of > > time. > > All discussions on mailing lists are unfocused and a waste of time to > some degree, even the best of them because by its very nature, email is > a time wasting tool. Let's not forget my bad jokes. I am still chuckling at JavaZero. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Martijn van Oosterhout wrote: -- Start of PGP signed section. > On Fri, May 19, 2006 at 04:41:20PM -0400, Bruce Momjian wrote: > > > Yes, the exeption applies to libreadline, which is why we can deliver > > > psql with libreadline linked on Linux, for example. But we can't on > > > Windows or Solaris. > > > > OK, where do you see this exception? I have not. > > The exception is not relevent in this case. The exception is to allow > GPL applications to work on non-free operating systems. Obviously a > GPL'd application on Windows can never supply the source to the Win32 > libraries. > > libreadline is not a problem because you can distribute postgresql > compiled with readline and comply with all licences involved > simultaneously. It doesn't work with openssl because the licence > requires things that are incompatable with the GPL. My question is whether psql using libreadline.so has to be GPL, meaning the psql source has to be included in a binary distribution. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Ühel kenal päeval, R, 2006-05-19 kell 22:53, kirjutas Martijn van Oosterhout: > libreadline is not a problem because you can distribute postgresql > compiled with readline and comply with all licences involved > simultaneously. oh? my impression was that we are clear, because libreadline is just one of "readline" implementations we support. > It doesn't work with openssl because the licence > requires things that are incompatable with the GPL. Still clients can compile/use libpq without OpenSSL and be on safe ground. > The openssl faq suggest that you can take advantage of the exception, > which reads: > > However, as a special exception, the source code distributed need not > include anything that is normally distributed (in either source or > binary form) with the major components (compiler, kernel, and so on) > of the operating system on which the executable runs, unless that > component itself accompanies the executable. > > I don't buy that argument, and I'm not the only one. OpenSSL is an > optional part of most Linuxes, so there's no way you can use that > exception. But on most linuxes optional parts ar also "normally distributed" :P Even network drivers may be counted optional for pure linux (kernel) experience, but are still normally distributed. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com NOTICE: This communication contains privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Jonah H. Harris wrote: On 5/19/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote: And with that, I am going to sit in a lawn chair and watch the bonfire. This is one of the finest examples of unfocused discussions I've ever seen on -hackers... while surely entertaining, what a huge waste of time. All discussions on mailing lists are unfocused and a waste of time to some degree, even the best of them because by its very nature, email is a time wasting tool. Have a great weekend! Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On 5/19/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote: And with that, I am going to sit in a lawn chair and watch the bonfire. This is one of the finest examples of unfocused discussions I've ever seen on -hackers... while surely entertaining, what a huge waste of time. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Ühel kenal päeval, R, 2006-05-19 kell 09:40, kirjutas Christopher Kings-Lynne: > > We also need better support for non C locales in tsearch. As I was porting > > mysql's sakila sample database I was reminded just how painful it is when > > you > > initdb in a non-supported locale (which is probably the default on the > > majority of distros out there) > > > In 8.2 tsearch2 supports utf8... Utf8 is encoding, but I guess that tsearch2 does not care much about locales ? tsearch2 does not do sorts, but it may care about upper()/lower() for languages that support it, so there our locale support should be good for utf8 encoding if we care about language-specific case insensitivity. -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Fri, May 19, 2006 at 04:41:20PM -0400, Bruce Momjian wrote: > > Yes, the exeption applies to libreadline, which is why we can deliver > > psql with libreadline linked on Linux, for example. But we can't on > > Windows or Solaris. > > OK, where do you see this exception? I have not. The exception is not relevent in this case. The exception is to allow GPL applications to work on non-free operating systems. Obviously a GPL'd application on Windows can never supply the source to the Win32 libraries. libreadline is not a problem because you can distribute postgresql compiled with readline and comply with all licences involved simultaneously. It doesn't work with openssl because the licence requires things that are incompatable with the GPL. The openssl faq suggest that you can take advantage of the exception, which reads: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. I don't buy that argument, and I'm not the only one. OpenSSL is an optional part of most Linuxes, so there's no way you can use that exception. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Andrew Dunstan wrote: > Bruce Momjian wrote: > > Rod Taylor wrote: > > > >> Exceptions exist in the GPL for libraries and tools included in the > >> operating system and this is enough in most cases. GPL applications on > >> Windows may have problems. > >> > > > > What exception, exactly? Does an exception apply to libreadline, > > because list I looked, it didn't. > > > > > > Yes, the exeption applies to libreadline, which is why we can deliver > psql with libreadline linked on Linux, for example. But we can't on > Windows or Solaris. OK, where do you see this exception? I have not. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Bruce Momjian wrote: Rod Taylor wrote: Exceptions exist in the GPL for libraries and tools included in the operating system and this is enough in most cases. GPL applications on Windows may have problems. What exception, exactly? Does an exception apply to libreadline, because list I looked, it didn't. Yes, the exeption applies to libreadline, which is why we can deliver psql with libreadline linked on Linux, for example. But we can't on Windows or Solaris. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Rod Taylor wrote: > Exceptions exist in the GPL for libraries and tools included in the > operating system and this is enough in most cases. GPL applications on > Windows may have problems. What exception, exactly? Does an exception apply to libreadline, because list I looked, it didn't. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
[EMAIL PROTECTED] ("Mark Woodward") writes:
>> Jim C. Nasby wrote:
>>> Maybe a compatability layer isn't worth doing, but I certainly
>>> think it's very much worthwhile for the community to do everything
>>> possible to encourage migration from MySQL. We should be able to
>>> lay claim to most advanced and most popular OSS database.
>>>
>>
>> We'll do that by concentrating on spiffy features, not
>> compatibility layers. I want people to use PostgreSQL because it's
>> the best, not because it's just like something else.
>>
>
> While I do agree with the ideal, the reality may not be good
> enough. Even I, a PostgreSQL user for a decade, have to use MySQL
> right now because that is what the client uses.
>
> Again, there is so much code for MySQL, a MySQL emulation layer, MEL
> for short, could allow plug and play compatibility for open source,
> and closed source, applications that otherwise would force a
> PostgreSQL user to hold his or her nose and use MySQL.
But this is essentially what killed off OS/2 in the marketplace.
IBM created a "good enough" emulation layer that it ran [early]
Windows(tm) applications sufficiently well that nobody bothered
porting applications to *properly* work with OS/2.
Microsoft then played off that with exceeding success; they made sure
that future versions of Windows(tm) were sufficiently different that
OS/2 was left orphaned.
We *are* in a sufficiently comparable state here; MySQL AB is *NOT*
our friend; they want to successfully 'take over the world,' at least
as far as they can do so with their product line...
--
"cbbrowne","@","cbbrowne.com"
http://cbbrowne.com/info/unix.html
CBS News report on Fort Worth tornado damage:
"Eight major downtown buildings were severely damaged and 1,000 homes
were damaged, with 95 uninhabitable. Gov. George W. Bush declared
Tarrant County a disaster area. Federal Emergency Management Agency
workers are expected to arrive sometime next week after required
paperwork is completed."
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Fri, May 19, 2006 at 03:39:23PM -0400, Mark Woodward wrote: > > > >> Actually, I think it's a lot more accurate to compare PostgreSQL and > >> MySQL as FreeBSD vs Linux from about 5 years ago. Back then FreeBSD was > >> clearly superior from a technology standpoint, and clearly playing > >> second-fiddle when it came to users. And now, Linux is actually > >> technically superior in most ways thanks to all the mindshare that's > >> been poured into it. > > > > And with that, I am going to sit in a lawn chair and watch the bonfire. > > Even I know that is NOT a discussion we want to start. Yeah, wasn't trying to start an OS flamewar; my point is that it's now pretty hard to find anything FreeBSD related/specific, and that the sheer popularity of Linux has given it a huge boost in terms of development. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
> >> Actually, I think it's a lot more accurate to compare PostgreSQL and >> MySQL as FreeBSD vs Linux from about 5 years ago. Back then FreeBSD was >> clearly superior from a technology standpoint, and clearly playing >> second-fiddle when it came to users. And now, Linux is actually >> technically superior in most ways thanks to all the mindshare that's >> been poured into it. > > And with that, I am going to sit in a lawn chair and watch the bonfire. > Even I know that is NOT a discussion we want to start. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Moving to -advocacy, bcc to -hackers. On Fri, May 19, 2006 at 08:11:42AM -0700, Joshua D. Drake wrote: > When MySQL is at that > >point, which database do you think executives will be choosing? The one > >with a very large userbase and lots of marketing and PR that they've > >heard plenty about, > > All due respect, Jim -- but don't you work for a publicly traded > database company that happens to have its own version of PostgreSQL? Actually, we haven't had a distribution of PostgreSQL since 8.0.3, and even then it was only a distribution; the bits were all community. > This is really a discussion for your marketing (and mine frankly) then > the PostgreSQL mailing lists :) Yes and no... should MySQL eventually become popular enough that there's little use of PostgreSQL that hurts the community just as much as it hurts our companies. In fact, I'd say it's already hurting the community more than our companies; look at how many people lament about running software XYZ because it only supports MySQL. Or about trying to find PostgreSQL hosting providers. But yes, the group of PostgreSQL companies should also be working to raise awareness of PostgreSQL as a very viable OSS database. Unfortunately, a lot of the commercial interest is in the higher-end market. And to a large extent, this really needs to be a grass-roots effort. After all, you don't win OSS mindshare by taking out ads or anything like that. So I think this really needs to be a joint venture between companies and the community. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Actually, I think it's a lot more accurate to compare PostgreSQL and MySQL as FreeBSD vs Linux from about 5 years ago. Back then FreeBSD was clearly superior from a technology standpoint, and clearly playing second-fiddle when it came to users. And now, Linux is actually technically superior in most ways thanks to all the mindshare that's been poured into it. And with that, I am going to sit in a lawn chair and watch the bonfire. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Fri, May 19, 2006 at 11:29:23AM -0400, Mark Woodward wrote: > I kind of agree with this statement, but while I was playing devils's > advocate and just grousing a bit about having to use MySQL, there is a > sort of reality of "openomics" where mind-share is everything. > > The more mind-share you have, the more opportunities you have and the more > resources become available. Not always, of course, look at OpenSSH, but > for the most part. > > As MySQL adds features, not matter how poorly implemented, and maintain a > migration path, we will never reach their users. > > PostgreSQL is better, true, but it is not ideal in many ways. It can be > best said that the difference between PostgreSQL and MySQL is similar to > the difference between Linux/BSD and Windows. Actually, I think it's a lot more accurate to compare PostgreSQL and MySQL as FreeBSD vs Linux from about 5 years ago. Back then FreeBSD was clearly superior from a technology standpoint, and clearly playing second-fiddle when it came to users. And now, Linux is actually technically superior in most ways thanks to all the mindshare that's been poured into it. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Alvaro Herrera wrote: Joshua D. Drake wrote: Martijn van Oosterhout wrote: On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote: The reality is that MySQL is widely supported by some very, shall we say, "interesting" open source projects and using these products with PostgreSQL would be a plus. The biggest headache I find with using postgres is that various GPL licenced programs have trouble directly shipping postgresql support because of our use of OpenSSL. Each and every one of those program needs to add an exception to their licence for distributors to distribute postgresql support. Why would that be the case... OpenSSL and PostgreSQL both are BSD licensed... Am I missing something? Advertising clause. PostgreSQL doesn't have it, OpenSSL does. Is that the same clause that caused the XFree86/X.Org fork? J -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Fri, 2006-05-19 at 09:11 -0700, Joshua D. Drake wrote: > Martijn van Oosterhout wrote: > > On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote: > >> The reality is that MySQL is widely supported by some very, shall we say, > >> "interesting" open source projects and using these products with > >> PostgreSQL would be a plus. > > > > The biggest headache I find with using postgres is that various GPL > > licenced programs have trouble directly shipping postgresql support > > because of our use of OpenSSL. Each and every one of those program > > needs to add an exception to their licence for distributors to > > distribute postgresql support. > > Why would that be the case... OpenSSL and PostgreSQL both are BSD > licensed... Am I missing something? OpenSSL is not the 3 clause BSD license, it also includes a number of advertising clauses that the GPL has never liked -- GPL must not be modified for derivatives but the advertising clauses are in addition to the GPL, so it must be modified for the combination. Exceptions exist in the GPL for libraries and tools included in the operating system and this is enough in most cases. GPL applications on Windows may have problems. http://www.openssl.org/support/faq.html#LEGAL2 2. Can I use OpenSSL with GPL software? On many systems including the major Linux and BSD distributions, yes (the GPL does not place restrictions on using libraries that are part of the normal operating system distribution). On other systems, the situation is less clear. Some GPL software copyright holders claim that you infringe on their rights if you use OpenSSL with their software on operating systems that don't normally include OpenSSL. If you develop open source software that uses OpenSSL, you may find it useful to choose an other license than the GPL, or state explicitly that "This program is released under the GPL with the additional exemption that compiling, linking, and/or using OpenSSL is allowed." If you are using GPL software developed by others, you may want to ask the copyright holder for permission to use their software with OpenSSL. OpenSSL License * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *"This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit. (http://www.openssl.org/)" * * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to *endorse or promote products derived from this software without *prior written permission. For written permission, please contact *[EMAIL PROTECTED] * * 5. Products derived from this software may not be called "OpenSSL" *nor may "OpenSSL" appear in their names without prior written *permission of the OpenSSL Project. * * 6. Redistributions of any form whatsoever must retain the following *acknowledgment: *"This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit (http://www.openssl.org/)" > > I'm thinking particularly of FreeRadius but there are others. More than > > once I thought while waiting for stuff to compile: if I'd chosen mysql > > I'd be done by now... > > > > Have a nice day, -- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Joshua D. Drake wrote: Martijn van Oosterhout wrote: On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote: The reality is that MySQL is widely supported by some very, shall we say, "interesting" open source projects and using these products with PostgreSQL would be a plus. The biggest headache I find with using postgres is that various GPL licenced programs have trouble directly shipping postgresql support because of our use of OpenSSL. Each and every one of those program needs to add an exception to their licence for distributors to distribute postgresql support. Why would that be the case... OpenSSL and PostgreSQL both are BSD licensed... Am I missing something? http://www.openssl.org/support/faq.html#LEGAL2 Of course, on that reasoning, they would need to provide a similar exception for libpq with or without openssl. More and more I love the fact that we don't play these games. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Joshua D. Drake wrote: > Martijn van Oosterhout wrote: > >On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote: > >>The reality is that MySQL is widely supported by some very, shall we say, > >>"interesting" open source projects and using these products with > >>PostgreSQL would be a plus. > > > >The biggest headache I find with using postgres is that various GPL > >licenced programs have trouble directly shipping postgresql support > >because of our use of OpenSSL. Each and every one of those program > >needs to add an exception to their licence for distributors to > >distribute postgresql support. > > Why would that be the case... OpenSSL and PostgreSQL both are BSD > licensed... Am I missing something? Advertising clause. PostgreSQL doesn't have it, OpenSSL does. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Martijn van Oosterhout wrote: On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote: The reality is that MySQL is widely supported by some very, shall we say, "interesting" open source projects and using these products with PostgreSQL would be a plus. The biggest headache I find with using postgres is that various GPL licenced programs have trouble directly shipping postgresql support because of our use of OpenSSL. Each and every one of those program needs to add an exception to their licence for distributors to distribute postgresql support. Why would that be the case... OpenSSL and PostgreSQL both are BSD licensed... Am I missing something? Joshua D. Drake I'm thinking particularly of FreeRadius but there are others. More than once I thought while waiting for stuff to compile: if I'd chosen mysql I'd be done by now... Have a nice day, -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Martijn van Oosterhout wrote: The biggest headache I find with using postgres is that various GPL licenced programs have trouble directly shipping postgresql support because of our use of OpenSSL. Each and every one of those program needs to add an exception to their licence for distributors to distribute postgresql support. They could distribute a non-ssl-enabled version, *if* they really need to include libpq in the package, or advise to to replace it with the common version if ssl is required. I bet >99 % of pgsql connections are not encrypted anyway. Regards, Andreas ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote: > The reality is that MySQL is widely supported by some very, shall we say, > "interesting" open source projects and using these products with > PostgreSQL would be a plus. The biggest headache I find with using postgres is that various GPL licenced programs have trouble directly shipping postgresql support because of our use of OpenSSL. Each and every one of those program needs to add an exception to their licence for distributors to distribute postgresql support. I'm thinking particularly of FreeRadius but there are others. More than once I thought while waiting for stuff to compile: if I'd chosen mysql I'd be done by now... Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
> Andrew Dunstan <[EMAIL PROTECTED]> writes: >> Mark Woodward wrote: >>> Again, there is so much code for MySQL, a MySQL emulation layer, MEL >>> for >>> short, could allow plug and play compatibility for open source, and >>> closed >>> source, applications that otherwise would force a PostgreSQL user to >>> hold >>> his or her nose and use MySQL. >>> >> If we had infinite resources this might make sense. We don't, so it >> doesn't. There is a real cost to producing a compatibility layer, and >> the cost will be those spiffy new features. > > The real problem is that there's a whole lot of stuff, such as mysql's > weak error checking, that I don't think a "compatibility layer" could > sanely provide. > I kind of agree with this statement, but while I was playing devils's advocate and just grousing a bit about having to use MySQL, there is a sort of reality of "openomics" where mind-share is everything. The more mind-share you have, the more opportunities you have and the more resources become available. Not always, of course, look at OpenSSH, but for the most part. As MySQL adds features, not matter how poorly implemented, and maintain a migration path, we will never reach their users. PostgreSQL is better, true, but it is not ideal in many ways. It can be best said that the difference between PostgreSQL and MySQL is similar to the difference between Linux/BSD and Windows. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
When MySQL is at that point, which database do you think executives will be choosing? The one with a very large userbase and lots of marketing and PR that they've heard plenty about, All due respect, Jim -- but don't you work for a publicly traded database company that happens to have its own version of PostgreSQL? This is really a discussion for your marketing (and mine frankly) then the PostgreSQL mailing lists :) Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Fri, May 19, 2006 at 01:26:34AM +0200, Dawid Kuroczko wrote: > Personally my opinion is that there is no point in pushing PostgreSQL > everywhere -- if there is no siginifcant performance gain, most managers > will refuse it, on the grounds that "if it ain't (too) broke, don't fix it". > The real places to "attack at" are the BIG dbs, the dataware housing > applications. Places where MySQL is not used, because someones > select count(*) should not kill the database. Because the queries > take few hours to complete "by design". This should be doable. :) The problem with limiting ourselves to going after only the 'high end' of databases is that MySQL is also pushing in that direction, but they have the advantage of a much larger user base than us. So in the not-to-distant future, a lot of people who are looking to come off of Oracle will look at both MySQL and PostgreSQL (in fact I'm sure there's already some people moving from Oracle to MySQL). When MySQL is at that point, which database do you think executives will be choosing? The one with a very large userbase and lots of marketing and PR that they've heard plenty about, or the one that might theoretically be technically superior but has a small userbase and they've never heard of? And if the technical people in the company are MySQL users, because that's the database they cut their teeth on... -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Am Freitag, 19. Mai 2006 02:35 schrieb Robert Treat: > On Thursday 18 May 2006 12:38, Josh Berkus wrote: > > Personally, I'd go after MSSQL before I bothered with MySQL. Sure, > > let's make *migration* easier for those who wake up and smell the BS, but > > migration can (and probably should) be one-way. > > If you want to get users to swtich to your software from your competitors, > you have to eliminate barriers, and a big one for any database is getting > locked into a specific one. People aren't going to take the time to try > switching to postgresql if they can't easily make it back to thier former > database. It's one of the reasons why PostgreSQL's standards compliance is > so important; if you want to swtich to a new database, your best bet is to > give PostgreSQL a shot, because even if you don't like it, we're not going > to try and trap you into our software with bunches of non-standard knobs. > Low barrier to exit == low barrier to entry. The way to go are standards. If postgresql supports standard-sql (like we all know it know), mysql-users has to justify their apps to use standard-sql. What they gain is not only compatibility with PostgreSQL but compatiblity with all database-servers, which supports this standard. They wont have much trouble to switch back to mysql or downgrade their postgresql to oracle ;-), if they follow standards. Also if PostgreSQL would have a compatibility-layer, it has to follow every quirk of mysql and will be measured by that. Much better is to promote users of mysql to use standards. Tommi ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Fri, May 19, 2006 13:25, Thomas Hallgren wrote: > If that's really true, then let's create a bidirectional compatibility > layer as a joint > venture with people from the MySQL camp. Should be a win-win situation. I > somehow doubt that > is the case. Important yes. But "just as important"? No way. I'm not too hopeful, for two reasons. First: MySQL is very, very different. I heard they just introduced a "create user" command like everybody else, but that's a drop in an ocean. I'm sure it's unintentional, but publishing a "quaint" SQL dialect amounts to a vendor-lock-in scheme--this time with the barn being locked before the cash cows have walked in. Second: management changes at MySQL seem to have favoured conventional business thinking over following the techs where no man has gone before. A year or two back we discussed porting libpqxx to MySQL so we'd have at least a strong, common C++ layer. Some of the technical people loved it, a provisional team was sketched out, and the idea was pitched to management. The argument: the more stable interfaces we share, the more confident corporate customers will feel adopting free databases. It didn't go anywhere. Reports I heard later amounted to "they don't see why they should spend the money." Jeroen ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Christopher Kings-Lynne wrote: If you want to get users to swtich to your software from your competitors, you have to eliminate barriers, and a big one for any database is getting locked into a specific one. People aren't going to take the time to try switching to postgresql if they can't easily make it back to thier former database. It's one of the reasons why PostgreSQL's standards compliance is so important; if you want to swtich to a new database, your best bet is to give PostgreSQL a shot, because even if you don't like it, we're not going to try and trap you into our software with bunches of non-standard knobs. Low barrier to exit == low barrier to entry. Another reason why a tool to export from pgsql to mysql is just as important as the vice versa... If that's really true, then let's create a bidirectional compatibility layer as a joint venture with people from the MySQL camp. Should be a win-win situation. I somehow doubt that is the case. Important yes. But "just as important"? No way. We would loose big time on the export side since the vendor lock-in aspect is seriously out balanced by current levels of standards compliance. On the other hand, we'd win by order of magnitude on the import side. I bet the MySQL people would be utterly uninterested in such a venture. I think that if anything should be done, we should concentrate on import and let the MySQL people worry about going the other way. Once it becomes "just as imporant", they will. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Chris Browne wrote:
[EMAIL PROTECTED] ("Marc G. Fournier") writes:
To give someone a running chance at migrating it to PostgreSQL, a
'MySQL compatibility module' would allow them to just plug the
existing DB in, and then work at improving sections of the code over
time ...
Hell, if done well, the module should be able to dump appropriately
'clean' PgSQL schemas ... as in your example elow about the domains ...
You can't have that because you essentially need to throw out four
aspects of fairly vital "data validation" functionality:
1. Dates cease to be validatable.
2. NULL and 0 and '' are all roughly equivalent, even though they
aren't.
3. Foreign key constraints have to be ignored.
4. You have to fabricate a locale offering a case-insensitive sort
order.
I suppose #4 isn't "vital data validation"...
But after you "gut" the PostgreSQL-based system of those four aspects
of data integrity, I'm not sure there's any remaining benefit to
having PostgreSQL in play...
Assuming the objective with a transition would be to improve on things, an alternative
approach could be to offer a three step migration path:
1. A dump/restore utility that dumps a MySQL database and restores it into a PostgreSQL
database. This utility must have plugin capabilities where logic can be added that deals
with cases #1, #2, and #3 above. It might be as simple as just logging incorrect records to
a file and skip them. A pre-defined set of generic plugins could be supplied that did just
that. A user would have the chance to replace them with customized plugins to cover for
special cases in his own app. Perl or PHP would probably be good candidates for plugin language.
2. Provide an add-on to the PostgreSQL parser that would make it accept MySQL syntax. The
database would still run untainted underneath so from this point on, no more invalid dates
or foreign keys can be entered. Some other add-ons are needed as well to cater for some sane
but non-standard MySQL behavior that PostgreSQL is lacking.
3. A good user guide that helps the user to, over time, move away from the non standard
MySQL specific expressions. The objective being to at some point skip the MySQL syntax layer
altogether.
Regards,
Thomas Hallgren
(dead serious this time)
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Christopher Kings-Lynne wrote: And MySQL is much closer to being a competitor now than they were in 4.1. And feature-wise they'll probably equal PostgreSQL in the next release. Will the features be anywhere near as robust or well thought out? No. But in a heck of a lot of companies that doesn't matter. Don't forget that they got nested transactions and PITR both before us. They will also shortly have really nice partitioning before us... ...don't underestimate their development speed. Second that. In addition they have (early) in-memory multi-node clustering and Jim Starkey is writing them a new transactional storage engine to replace the probably-soon-to-be-license-hampered Innodb... Cheers Mark ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
If you want to get users to swtich to your software from your competitors, you have to eliminate barriers, and a big one for any database is getting locked into a specific one. People aren't going to take the time to try switching to postgresql if they can't easily make it back to thier former database. It's one of the reasons why PostgreSQL's standards compliance is so important; if you want to swtich to a new database, your best bet is to give PostgreSQL a shot, because even if you don't like it, we're not going to try and trap you into our software with bunches of non-standard knobs. Low barrier to exit == low barrier to entry. Another reason why a tool to export from pgsql to mysql is just as important as the vice versa... Chris ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
We also need better support for non C locales in tsearch. As I was porting mysql's sakila sample database I was reminded just how painful it is when you initdb in a non-supported locale (which is probably the default on the majority of distros out there) In 8.2 tsearch2 supports utf8... ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
And MySQL is much closer to being a competitor now than they were in 4.1. And feature-wise they'll probably equal PostgreSQL in the next release. Will the features be anywhere near as robust or well thought out? No. But in a heck of a lot of companies that doesn't matter. Don't forget that they got nested transactions and PITR both before us. They will also shortly have really nice partitioning before us... ...don't underestimate their development speed. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Thursday 18 May 2006 12:38, Josh Berkus wrote:
> Personally, I'd go after MSSQL before I bothered with MySQL. Sure, let's
> make *migration* easier for those who wake up and smell the BS, but
> migration can (and probably should) be one-way.
>
If you want to get users to swtich to your software from your competitors, you
have to eliminate barriers, and a big one for any database is getting locked
into a specific one. People aren't going to take the time to try switching
to postgresql if they can't easily make it back to thier former database.
It's one of the reasons why PostgreSQL's standards compliance is so
important; if you want to swtich to a new database, your best bet is to give
PostgreSQL a shot, because even if you don't like it, we're not going to try
and trap you into our software with bunches of non-standard knobs. Low
barrier to exit == low barrier to entry.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Thursday 18 May 2006 16:17, Philippe Schmid wrote:
> As a users of both Postgres and MySQL, I would also say, better add
> missing features to Postgres than chasing some specialties that are
> going to vanish anyway in MySQL.
> I miss :
> - a core full-text indexing engine. Tsearch2 is nice, but not
> included. This is a feature often used by PHP/MySQL packages.
We also need better support for non C locales in tsearch. As I was porting
mysql's sakila sample database I was reminded just how painful it is when you
initdb in a non-supported locale (which is probably the default on the
majority of distros out there)
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On 5/18/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote: > > On May 17, 2006, at 8:08 PM, Mark Woodward wrote: > > >What is the best way to go about creating a "plug and play," > >PostgreSQL > >replacement for MySQL? I think the biggest problem getting PostgreSQL > >accepted is that so much code is available for MySQL. > > > http://pgfoundry.org/projects/mysqlcompat/ Even better would be coming up with a compatability mode, a la what EnterpriseDB has done for Oracle. I don't think we actually want such a mode. In theory it would be great, but in practise... Especially from performance standpoint. I mean, application for MySQL would usually be written as: quick connect, do a query, disconnect. No application-level caching, no connection keep-alive. First run on a similar hardware would be a performance disaster. PostgreSQL connection initialisation will be slower (yes, pgpool, but how much do you want to bet, the reaction would be: "you said compatibility mode! no mention of pgpool!"), and no caching would be noticable, to say the least. I don't want to suggest adding caching to postgresql (I know it isn't that great). I want to suggest that MySQL users are used to it and will be unhappy to part from it. So, if you want to help people migrate to Postgres, better tell them how to fix mysqlisms. I mean: "no replace into"? tell them about create trigger on insert to handle duplicates. No caching, tell them about memcached and its advantages. Tell how to use pgpool. Personally, I wish I had better knowledge of PostgreSQL years back, when one project was started... I didn't know PostgreSQL then, and well, MySQL outperformed it. Of course when real load was given, MyISAM were a performance disaster, but then there was InnoDB... And sometimes some developer will select count(*) on InnoDB, and InnoDB will make a temporary table with all the data, holding the lock on the table... And sometimes the replication will just break, and sometimes you need repair table. All the usual fun. ;) While I can talk to the DBAs and tell them about table partitioning, PITR, MVCC, online backups, etc, etc. then add spice with PL/pgSQL and other PL/*s the real problem is people are used to MySQL -- -- they know how to handle it, how to support it, what to expect from it. The bigger the company, the harder it is to convince people that they should start using something completely new. An important application with 1 or 2 people who know what to do, when after a major failure, restart doesn't help. This makes it very hard... Personally my opinion is that there is no point in pushing PostgreSQL everywhere -- if there is no siginifcant performance gain, most managers will refuse it, on the grounds that "if it ain't (too) broke, don't fix it". The real places to "attack at" are the BIG dbs, the dataware housing applications. Places where MySQL is not used, because someones select count(*) should not kill the database. Because the queries take few hours to complete "by design". This should be doable. :) Regards, Dawid ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Lukas Smith wrote: .. but spouting outdated FUD is really making you two look foolish. Wow. On a scale from 1 to 10 measuring seriousness, I'd put my posting on -4. I'd advice you to take a step back and get some distance if you consider it "outdated FUD". Regards, Thomas Hallgren ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
If we had infinite resources this might make sense. We don't, so it doesn't. There is a real cost to producing a compatibility layer, and the cost will be those spiffy new features. Let's get recursive queries, MERGE, and a couple more things and they will still be chasing our heels. As a users of both Postgres and MySQL, I would also say, better add missing features to Postgres than chasing some specialties that are going to vanish anyway in MySQL. I miss : - a core full-text indexing engine. Tsearch2 is nice, but not included. This is a feature often used by PHP/MySQL packages. - per table or column choice of char set/encoding - better configurations or a tool to give the user some clue how to optimize the postgres settings (I know, the pro will know every time, but not every MySQL user - potential Postgres convert is a pro, by large More high end features like these are also very welcomed... - recursive queries - better partitioning - multi-master sync - the compression thread is also interesting (cf IBM DB2 Viper about this) Till now, the postgres project managed to produce amazing stuff. Keeping the project focused will very probably be more difficult as more users are converted... Best regards, Philippe Schmid ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
[EMAIL PROTECTED] ("Marc G. Fournier") writes:
> To give someone a running chance at migrating it to PostgreSQL, a
> 'MySQL compatibility module' would allow them to just plug the
> existing DB in, and then work at improving sections of the code over
> time ...
>
> Hell, if done well, the module should be able to dump appropriately
> 'clean' PgSQL schemas ... as in your example elow about the domains ...
You can't have that because you essentially need to throw out four
aspects of fairly vital "data validation" functionality:
1. Dates cease to be validatable.
2. NULL and 0 and '' are all roughly equivalent, even though they
aren't.
3. Foreign key constraints have to be ignored.
4. You have to fabricate a locale offering a case-insensitive sort
order.
I suppose #4 isn't "vital data validation"...
But after you "gut" the PostgreSQL-based system of those four aspects
of data integrity, I'm not sure there's any remaining benefit to
having PostgreSQL in play...
--
"cbbrowne","@","cbbrowne.com"
http://cbbrowne.com/info/unix.html
CBS News report on Fort Worth tornado damage:
"Eight major downtown buildings were severely damaged and 1,000 homes
were damaged, with 95 uninhabitable. Gov. George W. Bush declared
Tarrant County a disaster area. Federal Emergency Management Agency
workers are expected to arrive sometime next week after required
paperwork is completed."
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
David Fetter wrote: On Thu, May 18, 2006 at 09:58:21PM +0200, Lukas Smith wrote: In what way is this outdated? Please provide a specific example. see below .. You have to understand that MySQL evolves just like PostgreSQL does. If it were true, I would have to understand it, but the way MySQL evolves is not even remotely like the way PostgreSQL does. Here are a few concrete differences: Ok, I was not trying to imply that MySQL evolves in the same way .. only that it also evolves. You've made some sweeping allegations here and no specifics. sweeping allegations? http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html SET [GLOBAL|SESSION] sql_mode='ALLOW_INVALID_DATES' That being said the solution is still lacking. I even filed a bug report over this: http://bugs.mysql.com/bug.php?id=17998 So I guess you can continue your commentary. Anyways, it was not my intention to educate PostgreSQL developers about MySQL, only that it would be wise not to make general comments about MySQL if you do not follow its development. regards, Lukas ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Mark Woodward wrote: >> Again, there is so much code for MySQL, a MySQL emulation layer, MEL for >> short, could allow plug and play compatibility for open source, and closed >> source, applications that otherwise would force a PostgreSQL user to hold >> his or her nose and use MySQL. >> > If we had infinite resources this might make sense. We don't, so it > doesn't. There is a real cost to producing a compatibility layer, and > the cost will be those spiffy new features. The real problem is that there's a whole lot of stuff, such as mysql's weak error checking, that I don't think a "compatibility layer" could sanely provide. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Thu, May 18, 2006 at 01:25:34PM -0700, Joshua D. Drake wrote: > > >I do agree that its probably not worth allocating core resources to > >this, but spouting outdated FUD is really making you two look foolish. > > And which FUD would this be? That Feb. 31st is a valid date in MySQL. You can now configure it to reject that (don't know if that's the default or not). > > > >You have to understand that MySQL evolves just like PostgreSQL does. So > >you better focus on advertising where PostgreSQL shines instead of > >poking fun at something you apparently do not follow. > > Uhmmm, I am not even going to bother responding to this part. It is > obvious that *you* don't follow MySQL versus PostgreSQL. > > No offense but the development models and thus evolution thereof are > completely different. You just proved one of my points. It's pretty easy for executives to understand that trying to store Feb. 31st in their database is probably a bad idea, but arguments about development models and their impact on software quality are likely to fall on deaf/befuddled ears. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
You've made some sweeping allegations here and no specifics. sweeping allegations? http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html SET [GLOBAL|SESSION] sql_mode='ALLOW_INVALID_DATES' Which can be turned off or on by any mysql user. Not to mention the fact that it is even an option. Joshua D. Drake follow its development. regards, Lukas -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
I do agree that its probably not worth allocating core resources to this, but spouting outdated FUD is really making you two look foolish. And which FUD would this be? You have to understand that MySQL evolves just like PostgreSQL does. So you better focus on advertising where PostgreSQL shines instead of poking fun at something you apparently do not follow. Uhmmm, I am not even going to bother responding to this part. It is obvious that *you* don't follow MySQL versus PostgreSQL. No offense but the development models and thus evolution thereof are completely different. Sincerely, Joshua D. Drake regards, Lukas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Thu, May 18, 2006 at 09:58:21PM +0200, Lukas Smith wrote: > Joshua D. Drake wrote: > > > >No we can't, because then we are taking an invalid date, which is > >potentially valid data (to the user) and modifying it to a valid > >date that is indeed invalid data. > > > >One of the reasons that mysql is just stupid. > > I do agree that its probably not worth allocating core resources to > this, but spouting outdated FUD is really making you two look > foolish. In what way is this outdated? Please provide a specific example. > You have to understand that MySQL evolves just like PostgreSQL does. If it were true, I would have to understand it, but the way MySQL evolves is not even remotely like the way PostgreSQL does. Here are a few concrete differences: * Community input. PostgreSQL's code all comes from the community. MySQL's all comes from employees of MySQL AB because MySQL AB requires that all developers sign over copyrights to MySQL AB. Independent developers are not naïf or foolish enough to contribute on those terms. * Standards compliance. PostgreSQL has bailed on quite a few features, and will in the future, in order to comply to SQL standards. * Marketing departments. PGDG doesn't have one, and if it did, it wouldn't have the power to drive features. > So you better focus on advertising where PostgreSQL shines instead > of poking fun at something you apparently do not follow. You've made some sweeping allegations here and no specifics. Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Joshua D. Drake wrote: Thomas Hallgren wrote: > Couldn't we just install something that replaced invalid dates with a randomly generated but otherwise correct dates? That way they would become completely invisible. No one could even tell that the date was invalid to start with. No we can't, because then we are taking an invalid date, which is potentially valid data (to the user) and modifying it to a valid date that is indeed invalid data. I think you should have read a `;-)' after Thomas' suggestion. ;-) Best Regards, Michael ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Joshua D. Drake wrote: Thomas Hallgren wrote: John DeSoi wrote: Right, you'll definitely need to hack the C source code to force PostgreSQL to accept invalid dates ;) http://sql-info.de/mysql/gotchas.html#1_14 Couldn't we just install something that replaced invalid dates with a randomly generated but otherwise correct dates? That way they would become completely invisible. No one could even tell that the date was invalid to start with. No we can't, because then we are taking an invalid date, which is potentially valid data (to the user) and modifying it to a valid date that is indeed invalid data. One of the reasons that mysql is just stupid. I do agree that its probably not worth allocating core resources to this, but spouting outdated FUD is really making you two look foolish. You have to understand that MySQL evolves just like PostgreSQL does. So you better focus on advertising where PostgreSQL shines instead of poking fun at something you apparently do not follow. regards, Lukas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Thomas Hallgren wrote: John DeSoi wrote: Right, you'll definitely need to hack the C source code to force PostgreSQL to accept invalid dates ;) http://sql-info.de/mysql/gotchas.html#1_14 Couldn't we just install something that replaced invalid dates with a randomly generated but otherwise correct dates? That way they would become completely invisible. No one could even tell that the date was invalid to start with. No we can't, because then we are taking an invalid date, which is potentially valid data (to the user) and modifying it to a valid date that is indeed invalid data. One of the reasons that mysql is just stupid. Joshua D. Drake Regards, Thomas Hallgren ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Thu, May 18, 2006 at 02:58:11PM -0400, Mark Woodward wrote: > > Jim C. Nasby wrote: > >> On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote: > >>> On May 17, 2006, at 8:08 PM, Mark Woodward wrote: > >>> > What is the best way to go about creating a "plug and play," > PostgreSQL > replacement for MySQL? I think the biggest problem getting PostgreSQL > accepted is that so much code is available for MySQL. > >>> > >>> http://pgfoundry.org/projects/mysqlcompat/ > >> > >> Even better would be coming up with a compatability mode, a la what > >> EnterpriseDB has done for Oracle. > > > > Good Lord NO. I don't want a bunch of hacked up code *because* MySQL > > does it this way, running on top of PostgreSQL. > > > > I want to run PostgreSQL. If you want to run MySQL, run MySQL. If you > > want to run Oracle, run Oracle. > > It isn't always about what we want to do, unfortunately, sometimes it has > to do with external factors outside of our control. > > The reality is that MySQL is widely supported by some very, shall we say, > "interesting" open source projects and using these products with > PostgreSQL would be a plus. > > I ask you, try to find some PHP/Open Source projects that support > PostgreSQL just as well as MySQL? Most don't even support PostgreSQL. Which means most ISPs don't support PostgreSQL. And most OSS users don't get exposed to PostgreSQL. Which leads to more OSS that doesn't support PostgreSQL... -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Mark Woodward wrote: Jim C. Nasby wrote: Maybe a compatability layer isn't worth doing, but I certainly think it's very much worthwhile for the community to do everything possible to encourage migration from MySQL. We should be able to lay claim to most advanced and most popular OSS database. We'll do that by concentrating on spiffy features, not compatibility layers. I want people to use PostgreSQL because it's the best, not because it's just like something else. While I do agree with the ideal, the reality may not be good enough. Even I, a PostgreSQL user for a decade, have to use MySQL right now because that is what the client uses. Again, there is so much code for MySQL, a MySQL emulation layer, MEL for short, could allow plug and play compatibility for open source, and closed source, applications that otherwise would force a PostgreSQL user to hold his or her nose and use MySQL. If we had infinite resources this might make sense. We don't, so it doesn't. There is a real cost to producing a compatibility layer, and the cost will be those spiffy new features. Let's get recursive queries, MERGE, and a couple more things and they will still be chasing our heels. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
While I do agree with the ideal, the reality may not be good enough. Even I, a PostgreSQL user for a decade, have to use MySQL right now because that is what the client uses. Then you aren't choosing your clients wisely. :) I am not trying to be rude, but if you don't want to use MySQL, don't. We don't and we are testament to the fact that it is indeed possible to make a living off of JUST PostgreSQL. The only time we touch a different database is to MIGRATE from that database. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
John DeSoi wrote: Right, you'll definitely need to hack the C source code to force PostgreSQL to accept invalid dates ;) http://sql-info.de/mysql/gotchas.html#1_14 Couldn't we just install something that replaced invalid dates with a randomly generated but otherwise correct dates? That way they would become completely invisible. No one could even tell that the date was invalid to start with. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
> Jim C. Nasby wrote: >> Maybe a compatability layer isn't worth doing, but I certainly think >> it's very much worthwhile for the community to do everything possible to >> encourage migration from MySQL. We should be able to lay claim to most >> advanced and most popular OSS database. >> > > We'll do that by concentrating on spiffy features, not compatibility > layers. I want people to use PostgreSQL because it's the best, not > because it's just like something else. > While I do agree with the ideal, the reality may not be good enough. Even I, a PostgreSQL user for a decade, have to use MySQL right now because that is what the client uses. Again, there is so much code for MySQL, a MySQL emulation layer, MEL for short, could allow plug and play compatibility for open source, and closed source, applications that otherwise would force a PostgreSQL user to hold his or her nose and use MySQL. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
> Jim C. Nasby wrote: >> On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote: >>> On May 17, 2006, at 8:08 PM, Mark Woodward wrote: >>> What is the best way to go about creating a "plug and play," PostgreSQL replacement for MySQL? I think the biggest problem getting PostgreSQL accepted is that so much code is available for MySQL. >>> >>> http://pgfoundry.org/projects/mysqlcompat/ >> >> Even better would be coming up with a compatability mode, a la what >> EnterpriseDB has done for Oracle. > > Good Lord NO. I don't want a bunch of hacked up code *because* MySQL > does it this way, running on top of PostgreSQL. > > I want to run PostgreSQL. If you want to run MySQL, run MySQL. If you > want to run Oracle, run Oracle. It isn't always about what we want to do, unfortunately, sometimes it has to do with external factors outside of our control. The reality is that MySQL is widely supported by some very, shall we say, "interesting" open source projects and using these products with PostgreSQL would be a plus. I ask you, try to find some PHP/Open Source projects that support PostgreSQL just as well as MySQL? Most don't even support PostgreSQL. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Jim C. Nasby wrote: Maybe a compatability layer isn't worth doing, but I certainly think it's very much worthwhile for the community to do everything possible to encourage migration from MySQL. We should be able to lay claim to most advanced and most popular OSS database. We'll do that by concentrating on spiffy features, not compatibility layers. I want people to use PostgreSQL because it's the best, not because it's just like something else. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Thu, May 18, 2006 at 01:22:55PM -0500, Jim C. Nasby wrote: > On Thu, May 18, 2006 at 11:09:28AM -0700, David Fetter wrote: > > postgres=# CREATE TABLE dual(); > > CREATE TABLE > > You forgot to populate it. Oh, right. :) postgres=# CREATE TABLE dual AS SELECT 1; SELECT Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
* Joshua D. Drake ([EMAIL PROTECTED]) wrote: > And to be frank, I don't think we should waste our time on MySQL. It > isn't a competitor, it just thinks it is. We should focus on our real > competition which is DB2, MSSQL, and Oracle. One thing which would be kind of nice would be to have a mapping for the common commands. A friend of mine did this with a bit of perl so he could have a single SQL script that could run against both Postgres and Oracle. His thought was actually just an aliasing ability in psql so that you could, for example, alias 'desc' to '\d' and '@' to '\i'. This would have also helped me out with some projects for school- the main issues I ran into were that Oracle required a cascade-drop to include the keyword 'constraints' (which Postgres correctly forbids) and that Oracle uses 'MINUS' instead of 'EXCEPT' (where 'EXCEPT' is the SQL standard, which Oracle doesn't accept for some reason. :/). Just some thoughts, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
And MySQL is much closer to being a competitor now than they were in 4.1. And feature-wise they'll probably equal PostgreSQL in the next release. Will the features be anywhere near as robust or well thought out? No. But in a heck of a lot of companies that doesn't matter. Your kidding right? Have you seen their "features"? Look at what their stored procedures are actually capable of. The only thing that MySQL *might* pull off is a really good storage backend finally. Maybe a compatability layer isn't worth doing, but I certainly think it's very much worthwhile for the community to do everything possible to encourage migration from MySQL. We should be able to lay claim to most advanced and most popular OSS database. Oh absolutely, I agree with you here but in order to do so in the most productive manner possible the community would have to be willing to be much more aggressive and much more antagnositic that I believe the community has the stomach for. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Thu, May 18, 2006 at 02:56:12PM -0300, Marc G. Fournier wrote: > the point isn't whether or not MySQL is a competitor ... the point is that > there are *alot* of MySQL based applications out there that are a major > PITA to convert (or get converted) all at once ... More importantly, there's a lot of MySQL *users*, and they get to influence which database is chosen in many companies. For many years, FreeBSD was far superior technologically to Linux, but Linux had the popularity to make it into the enterprise. And MySQL is much closer to being a competitor now than they were in 4.1. And feature-wise they'll probably equal PostgreSQL in the next release. Will the features be anywhere near as robust or well thought out? No. But in a heck of a lot of companies that doesn't matter. Maybe a compatability layer isn't worth doing, but I certainly think it's very much worthwhile for the community to do everything possible to encourage migration from MySQL. We should be able to lay claim to most advanced and most popular OSS database. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Thu, May 18, 2006 at 11:09:28AM -0700, David Fetter wrote: > postgres=# CREATE TABLE dual(); > CREATE TABLE You forgot to populate it. In reality I think you'd want dual to be a view on SELECT 1; or whatever the appropriate value is. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Thu, May 18, 2006 at 02:56:12PM -0300, Marc G. Fournier wrote: > On Thu, 18 May 2006, Joshua D. Drake wrote: > > >I understand the idea but I personally don't like it. I am not really > >interested in cross-database compatible code. 9 times out of 10 it is > >hacky, slow and lacks a solid supportable model because you are always > >taking into account *the other* databases the application supports. > > I don't disagree about the 'hacky, slow and lacks ...' ... but, > there are alot of MySQL based apps out there that are just *way too > big* to convert wholesale to PostgreSQL that, in all honesty, are > better suited to PostgreSQL ... They're not too big when critical data is in there. Then it's a matter of what cost to make this wrong decision and have to fix it. > To give someone a running chance at migrating it to PostgreSQL, a > 'MySQL compatibility module' would allow them to just plug the > existing DB in, and then work at improving sections of the code over > time ... You cannot cross a chasm in two steps. MySQL apps don't generally lend themselves to incremental improvements because they are so tightly tied to MySQL's misbehaviors. It would be silly and dangerous to give people the misapprehension that this transition can be made painlessly or at low cost. Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Thu, May 18, 2006 at 10:35:48AM -0700, Joshua D. Drake wrote: > I understand the idea but I personally don't like it. I am not > really interested in cross-database compatible code. 9 times out of > 10 it is hacky, slow and lacks a solid supportable model because you > are always taking into account *the other* databases the application > supports. > > And to be frank, I don't think we should waste our time on MySQL. It > isn't a competitor, it just thinks it is. We should focus on our > real competition which is DB2, MSSQL, and Oracle. > > If we want to create contrib modules that have types etc... that > help port from Oracle to PostgreSQL or DB2 to PostgreSQL I am all > for it. > > The first thing that comes to mind is a set of domains that > implement Oracle types (names) as PostgreSQL types. > > Here's a start ;) > > postgres=# create domain varchar2 AS text; > CREATE DOMAIN > postgres=# create domain clob as text; > CREATE DOMAIN > postgres=# create domain blob as bytea; > CREATE DOMAIN > postgres=# create domain number as integer; > CREATE DOMAIN > postgres=# postgres=# CREATE TABLE dual(); CREATE TABLE Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Marc, > To give someone a running chance at migrating it to PostgreSQL, a 'MySQL > compatibility module' would allow them to just plug the existing DB in, > and then work at improving sections of the code over time ... Have you even looked at KL's mysqlcompat? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Thu, 18 May 2006, Joshua D. Drake wrote: I understand the idea but I personally don't like it. I am not really interested in cross-database compatible code. 9 times out of 10 it is hacky, slow and lacks a solid supportable model because you are always taking into account *the other* databases the application supports. I don't disagree about the 'hacky, slow and lacks ...' ... but, there are alot of MySQL based apps out there that are just *way too big* to convert wholesale to PostgreSQL that, in all honesty, are better suited to PostgreSQL ... To give someone a running chance at migrating it to PostgreSQL, a 'MySQL compatibility module' would allow them to just plug the existing DB in, and then work at improving sections of the code over time ... Hell, if done well, the module should be able to dump appropriately 'clean' PgSQL schemas ... as in your example elow about the domains ... something like: postgres=# create domain varchar2 AS text; CREATE DOMAIN postgres=# create table test ( mytext varchar2 ); should dump out to: create tabel test ( mytext text ); So, developer would be able to load the MySQL schema and run the application, but would also be able to improve the code in the application and dump out a PgSQL clean schema so that the next person, in theory, wouldn't even need the MySQL module ... the point isn't whether or not MySQL is a competitor ... the point is that there are *alot* of MySQL based applications out there that are a major PITA to convert (or get converted) all at once ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
'k, so you want "pure PostgreSQL" ... but, shouldn't it be possible, with all of our CREATE FUNCTION / RULES / etc features to create a 'translation layer' that could be loaded, like anything else in contrib? Sure but that isn't what was suggested :) Hell, even if it gave an initial "in" for MySQL software developers to get their code running on PostgreSQL, and then when they come out that "do this is slower under PostgreSQL", they could optimize their code appropriately? I understand the idea but I personally don't like it. I am not really interested in cross-database compatible code. 9 times out of 10 it is hacky, slow and lacks a solid supportable model because you are always taking into account *the other* databases the application supports. And to be frank, I don't think we should waste our time on MySQL. It isn't a competitor, it just thinks it is. We should focus on our real competition which is DB2, MSSQL, and Oracle. If we want to create contrib modules that have types etc... that help port from Oracle to PostgreSQL or DB2 to PostgreSQL I am all for it. The first thing that comes to mind is a set of domains that implement Oracle types (names) as PostgreSQL types. Here's a start ;) postgres=# create domain varchar2 AS text; CREATE DOMAIN postgres=# create domain clob as text; CREATE DOMAIN postgres=# create domain blob as bytea; CREATE DOMAIN postgres=# create domain number as integer; CREATE DOMAIN postgres=# Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Thu, 18 May 2006, Joshua D. Drake wrote: Jim C. Nasby wrote: On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote: On May 17, 2006, at 8:08 PM, Mark Woodward wrote: What is the best way to go about creating a "plug and play," PostgreSQL replacement for MySQL? I think the biggest problem getting PostgreSQL accepted is that so much code is available for MySQL. http://pgfoundry.org/projects/mysqlcompat/ Even better would be coming up with a compatability mode, a la what EnterpriseDB has done for Oracle. Good Lord NO. I don't want a bunch of hacked up code *because* MySQL does it this way, running on top of PostgreSQL. 'k, so you want "pure PostgreSQL" ... but, shouldn't it be possible, with all of our CREATE FUNCTION / RULES / etc features to create a 'translation layer' that could be loaded, like anything else in contrib? Hell, even if it gave an initial "in" for MySQL software developers to get their code running on PostgreSQL, and then when they come out that "do this is slower under PostgreSQL", they could optimize their code appropriately? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Josh Berkus wrote: > Personally, I'd go after MSSQL before I bothered with MySQL. Sure, let's > make *migration* easier for those who wake up and smell the BS, but migration > can (and probably should) be one-way. Yeah. Let's write a Transact-SQL PL handler. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Jim C. Nasby wrote: On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote: On May 17, 2006, at 8:08 PM, Mark Woodward wrote: What is the best way to go about creating a "plug and play," PostgreSQL replacement for MySQL? I think the biggest problem getting PostgreSQL accepted is that so much code is available for MySQL. http://pgfoundry.org/projects/mysqlcompat/ Even better would be coming up with a compatability mode, a la what EnterpriseDB has done for Oracle. Good Lord NO. I don't want a bunch of hacked up code *because* MySQL does it this way, running on top of PostgreSQL. I want to run PostgreSQL. If you want to run MySQL, run MySQL. If you want to run Oracle, run Oracle. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On May 18, 2006, at 12:24 PM, Jim C. Nasby wrote: Even better would be coming up with a compatability mode, a la what EnterpriseDB has done for Oracle. Right, you'll definitely need to hack the C source code to force PostgreSQL to accept invalid dates ;) http://sql-info.de/mysql/gotchas.html#1_14 John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
All, > > >What is the best way to go about creating a "plug and play," > > >PostgreSQL > > >replacement for MySQL? I think the biggest problem getting PostgreSQL > > >accepted is that so much code is available for MySQL. > > > > http://pgfoundry.org/projects/mysqlcompat/ > > Even better would be coming up with a compatability mode, a la what > EnterpriseDB has done for Oracle. Um, no offense, but why? Do we really *want* to seek out thousands of users who won't pay anyone for support, don't care about data integrity, and regard the database as an enhanced flat file?Who adore non-standard syntax like `db_object_name` and REPLACE INTO? Who want to just get free downloads and not contribute to a project? Personally, I'd go after MSSQL before I bothered with MySQL. Sure, let's make *migration* easier for those who wake up and smell the BS, but migration can (and probably should) be one-way. If we're talking about other OSS projects, then I think it makes more sense for us to help those projects add PostgreSQL support. And do promote the projects that already *do* support us. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote: > > On May 17, 2006, at 8:08 PM, Mark Woodward wrote: > > >What is the best way to go about creating a "plug and play," > >PostgreSQL > >replacement for MySQL? I think the biggest problem getting PostgreSQL > >accepted is that so much code is available for MySQL. > > > http://pgfoundry.org/projects/mysqlcompat/ Even better would be coming up with a compatability mode, a la what EnterpriseDB has done for Oracle. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
* Mark Woodward: > "On the other hand, you shouldn't use mysql_use_result() if you are doing > a lot of processing for each row on the client side, or if the output is > sent to a screen on which the user may type a ^S (stop scroll). This ties > up the server and prevent other threads from updating any tables from > which the data is being fetched." > > How do busy web sites work like this? Any system based on locking exhibits this problem. Even with MVCC, you can run into it if you've got multiple writers. As a rule of thumb, I never perform network I/O within transactions which update the database (or "read the database", for systems without MVCC). ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
On May 17, 2006, at 8:08 PM, Mark Woodward wrote: What is the best way to go about creating a "plug and play," PostgreSQL replacement for MySQL? I think the biggest problem getting PostgreSQL accepted is that so much code is available for MySQL. http://pgfoundry.org/projects/mysqlcompat/ John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Mark Woodward wrote: > Sorry to interrupt, but I have had the "opportinuty" to have to work with > MySQL. This nice little gem is packed away in the reference for > mysql_use_result(). > > "On the other hand, you shouldn't use mysql_use_result() if you are doing > a lot of processing for each row on the client side, or if the output is > sent to a screen on which the user may type a ^S (stop scroll). This ties > up the server and prevent other threads from updating any tables from > which the data is being fetched." > > How do busy web sites work like this? > > What is the best way to go about creating a "plug and play," PostgreSQL > replacement for MySQL? I think the biggest problem getting PostgreSQL > accepted is that so much code is available for MySQL. That reminds me of the Twilight Zone episode where the guy had a stopwatch that stopped time: http://en.wikipedia.org/wiki/A_Kind_of_a_Stopwatch_(The_Twilight_Zone) -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
