Thread: Feedback from LinuxWorld, London
Reposted with attachment now accessible by link: http://pgfoundry.org/docman/view.php/1000047/91/PostgreSQL_Flyer.ppt -------- Forwarded Message -------- From: Simon Riggs <simon@2ndquadrant.com> To: pgsql-advocacy@postgresql.org Cc: Mark Cave-Ayland <m.cave-ayland@webbased.co.uk>, helen@2ndquadrant.com Subject: Feedback from LinuxWorld, London Date: Fri, 07 Oct 2005 12:28:00 +0100 Mark Cave-Ayland, Helen Barnes and I have just completed running the PostgreSQL stand at LinuxWorld, London. (First off: thanks guys - apologies were received from number of others unable to make it at last moment). The stand was huge, in comparison to last year: we were provided with a corner stand right in the main thoroughfare and the stand was very busy for the whole two days. One of the surprising and most pleasant things was the constant stream of people coming up and saying "we know you guys are great, much better than X; thanks very much for your efforts" and constantly shaking hands. I wanted to record some lessons-learned for advocacy, based upon these basic observations which we have pooled: Questions that got asked multiple times, in very rapidly descending frequency order were: 1= How do you differ from MySQL ? (All questioners assumed they would be the same, apart from the differences, rather than assuming they were different and asking for similarities...) 1= Do you support Replication/Fail-over/Load-balancing? Where can I get information on it? 3. Where can I get support/hosting/training ? 4. What type of licence is it under? Will it always be free? 5. Is the Windows port just as good as the Linux one? There were no questions at all on... 1. Certification 2. Object Relational stuff 3. I need this new really advanced, complex feature: **everything** was about basics of compatibility, availability and access to information about PostgreSQL which is out there but people didn't know it. Main complaint about PostgreSQL 1. It isn't compatible with MySQL. I tried to port application X, which only runs on MySQL and I couldn't get it to work. 2. It's slow (and I know this because): - I ported this query from MySQL and it ran slow - MySQL told me/I read it 3. I love Postgres, but at work we use X instead. In general, stand visitors perceived these other products as competitors (numbers are ratios, rather than a visitor count). MySQL 25 Oracle 5 SQLServer 2 Ingres 1 From those observations, my own personal lessons learned would be: - PostgreSQL has connected strongly with most technical staff that know anything about databases. There is nothing to worry about in terms of core functionality. PostgreSQL has connected very poorly with two groups: technical people who are aware of, but know nothing about databases and database final-decision-makers. - Many current MySQL users would like to adopt PostgreSQL but feel unable to do so because their application package does not support PostgreSQL at all/well enough or they feel there are technical issues with the MySQL to PostgreSQL code (not data) migration. - Information about replication is not getting out there, even to the people who know and love PostgreSQL. - Most people's perception is that MySQL is PostgreSQL's competitor, and my observation is that we don't specifically provide any direct information or refutation to answer this Most Frequent Question. [Objective feedback I have received was that the PostgreSQL people on stand handled this question professionally and credibly by explaining the differences and encouraging people to examine this for themselves, rather than being dismissive or rude.] I've attached the flyer we were giving out to people. We gave out every single one of these, running out near end of second day. Best Regards, Simon Riggs
Anyone else having trouble with that link? It's coming out as a blank presentation for me. On Sun, Oct 09, 2005 at 09:41:48PM +0100, Simon Riggs wrote: > > Reposted with attachment now accessible by link: > http://pgfoundry.org/docman/view.php/1000047/91/PostgreSQL_Flyer.ppt > > -------- Forwarded Message -------- > From: Simon Riggs <simon@2ndquadrant.com> > To: pgsql-advocacy@postgresql.org > Cc: Mark Cave-Ayland <m.cave-ayland@webbased.co.uk>, > helen@2ndquadrant.com > Subject: Feedback from LinuxWorld, London > Date: Fri, 07 Oct 2005 12:28:00 +0100 > > Mark Cave-Ayland, Helen Barnes and I have just completed running the > PostgreSQL stand at LinuxWorld, London. (First off: thanks guys - > apologies were received from number of others unable to make it at last > moment). > > The stand was huge, in comparison to last year: we were provided with a > corner stand right in the main thoroughfare and the stand was very busy > for the whole two days. One of the surprising and most pleasant things > was the constant stream of people coming up and saying "we know you guys > are great, much better than X; thanks very much for your efforts" and > constantly shaking hands. > > I wanted to record some lessons-learned for advocacy, based upon these > basic observations which we have pooled: > > Questions that got asked multiple times, in very rapidly descending > frequency order were: > > 1= How do you differ from MySQL ? (All questioners assumed they would be > the same, apart from the differences, rather than assuming they were > different and asking for similarities...) > > 1= Do you support Replication/Fail-over/Load-balancing? Where can I get > information on it? > > 3. Where can I get support/hosting/training ? > > 4. What type of licence is it under? Will it always be free? > > 5. Is the Windows port just as good as the Linux one? > > There were no questions at all on... > > 1. Certification > > 2. Object Relational stuff > > 3. I need this new really advanced, complex feature: **everything** was > about basics of compatibility, availability and access to information > about PostgreSQL which is out there but people didn't know it. > > Main complaint about PostgreSQL > > 1. It isn't compatible with MySQL. I tried to port application X, which > only runs on MySQL and I couldn't get it to work. > > 2. It's slow (and I know this because): > - I ported this query from MySQL and it ran slow > - MySQL told me/I read it > > 3. I love Postgres, but at work we use X instead. > > In general, stand visitors perceived these other products as competitors > (numbers are ratios, rather than a visitor count). > > MySQL 25 > Oracle 5 > SQLServer 2 > Ingres 1 > > >From those observations, my own personal lessons learned would be: > > - PostgreSQL has connected strongly with most technical staff that know > anything about databases. There is nothing to worry about in terms of > core functionality. PostgreSQL has connected very poorly with two > groups: technical people who are aware of, but know nothing about > databases and database final-decision-makers. > > - Many current MySQL users would like to adopt PostgreSQL but feel > unable to do so because their application package does not support > PostgreSQL at all/well enough or they feel there are technical issues > with the MySQL to PostgreSQL code (not data) migration. > > - Information about replication is not getting out there, even to the > people who know and love PostgreSQL. > > - Most people's perception is that MySQL is PostgreSQL's competitor, and > my observation is that we don't specifically provide any direct > information or refutation to answer this Most Frequent Question. > [Objective feedback I have received was that the PostgreSQL people on > stand handled this question professionally and credibly by explaining > the differences and encouraging people to examine this for themselves, > rather than being dismissive or rude.] > > I've attached the flyer we were giving out to people. We gave out every > single one of these, running out near end of second day. > > Best Regards, Simon Riggs > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Simon Riggs wrote: > - PostgreSQL has connected strongly with most technical staff that > know anything about databases. There is nothing to worry about in > terms of core functionality. PostgreSQL has connected very poorly > with two groups: technical people who are aware of, but know nothing > about databases and database final-decision-makers. Problem is, these people do not go to the expos. At the expos you cater to the technical people so they can in turn influence the "decision makers". > - Many current MySQL users would like to adopt PostgreSQL but feel > unable to do so because their application package does not support > PostgreSQL at all/well enough or they feel there are technical issues > with the MySQL to PostgreSQL code (not data) migration. And of course they are right. Porting from MySQL to PostgreSQL is a problem, one which could only be solved by dumbing down PostgreSQL to accept many of MySQL's idiosyncracies, which isn't going to happen. > - Most people's perception is that MySQL is PostgreSQL's competitor, > and my observation is that we don't specifically provide any direct > information or refutation to answer this Most Frequent Question. > [Objective feedback I have received was that the PostgreSQL people on > stand handled this question professionally and credibly by explaining > the differences and encouraging people to examine this for > themselves, rather than being dismissive or rude.] "See for yourself" has always worked best at the expos I was involved in, but the question does get annoying... -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Mon, Oct 10, 2005 at 07:19:47PM +0200, Peter Eisentraut wrote: > > - Many current MySQL users would like to adopt PostgreSQL but feel > > unable to do so because their application package does not support > > PostgreSQL at all/well enough or they feel there are technical issues > > with the MySQL to PostgreSQL code (not data) migration. > > And of course they are right. Porting from MySQL to PostgreSQL is a > problem, one which could only be solved by dumbing down PostgreSQL to > accept many of MySQL's idiosyncracies, which isn't going to happen. There are many features that could be implimented in PostgreSQL in a way that was both logical and supported MySQL converters, though. The recent discussion on one of the lists about adding enum as a type is an example. I'm sure there are others. I think the best way to increase migration from MySQL to PostgreSQL would be to find out what the biggest pains are for users attempting to migrate and then figure out how we can reduce that pain. In some cases these solutions might be adding features to PostgreSQL, but many of them might just involve improving existing migration tools. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Peter, Simon: First off, Simon, could you look at the Press FAQ to see if there's anything missing based on your experience at LWE-SF? http://pgfoundry.org/docman/view.php/1000047/26/press_faq.xhtml > And of course they are right. Porting from MySQL to PostgreSQL is a > problem, one which could only be solved by dumbing down PostgreSQL to > accept many of MySQL's idiosyncracies, which isn't going to happen. Well, better migration tools would be a start. PHP's gradual transition to PDO (and working with the PDO folks to make PDO_pgsql better, like not doing count(*)) will help a lot too; the biggest MySQL migration complaints I here are from users of PHP stuff like *Nuke and various Wikis which sprinkle SQL throughout the interface code. More important than any of these would be a 5-page guide, "Migration Tips from MySQL to PostgreSQL." -- --Josh Josh Berkus Aglio Database Solutions San Francisco
On Mon, 10 Oct 2005, Jim C. Nasby wrote: > On Mon, Oct 10, 2005 at 07:19:47PM +0200, Peter Eisentraut wrote: >>> - Many current MySQL users would like to adopt PostgreSQL but feel >>> unable to do so because their application package does not support >>> PostgreSQL at all/well enough or they feel there are technical issues >>> with the MySQL to PostgreSQL code (not data) migration. >> >> And of course they are right. Porting from MySQL to PostgreSQL is a >> problem, one which could only be solved by dumbing down PostgreSQL to >> accept many of MySQL's idiosyncracies, which isn't going to happen. > > There are many features that could be implimented in PostgreSQL in a way > that was both logical and supported MySQL converters, though. The recent > discussion on one of the lists about adding enum as a type is an > example. I'm sure there are others. > > I think the best way to increase migration from MySQL to PostgreSQL > would be to find out what the biggest pains are for users attempting to > migrate and then figure out how we can reduce that pain. In some cases > these solutions might be adding features to PostgreSQL, but many of them > might just involve improving existing migration tools. Couldn't these features be mostly added as a 'MySQL Compatibility add-on'? For instance, the enum type you list above ... ? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On 10/10/05, Josh Berkus <josh@agliodbs.com> wrote: > Well, better migration tools would be a start. PHP's gradual transition to > PDO (and working with the PDO folks to make PDO_pgsql better, like not > doing count(*)) will help a lot too; the biggest MySQL migration > complaints I here are from users of PHP stuff like *Nuke and various Wikis > which sprinkle SQL throughout the interface code. That is because the recent generations of web developers grew up (and continue to grow up) with MySQL as the 'default' database, and thus think it is perfectly normal to scatter their DDL/DML throughout the source tree of their apps. This is what I am cleaning up in Joomla! with the 1.2 release, which has been necessitated by the inclusion of ADOdb (and therefore PostgreSQL and others). I cannot wait to get that work started! :-D > More important than any of these would be a 5-page guide, "Migration Tips > from MySQL to PostgreSQL." And not just about SQL, but focus on the operational/administrative aspects. You wouldn't believe how frustrated PHP/MySQL-ers get after losing an hour with the "tcp sockets not enabled by default" problem when trying to evaluate PostgreSQL for the first time. Before they even learn how to connect to the database they are already frustrated and feeling helpless... I'm trying to convince the other Joomla! core developers to use PostgreSQL as the standard reference/development platform, in order to get closer to the SQL standards. If I end up writing any tutorial-type stuff I will pass it along over here. Wish me luck ;-) One thing for sure though - as both PHP matures as a technology, and web developers also gain sophistication, PostgreSQL is uniquely positioned as the one F/OSS database that will meet their needs. I see a great opportunity here, and Oracle's purchase of Innobase - and the resulting drama across the internet - will also push more web developers towards PostgreSQL, even if only for evaluation. -- Mitch
Mitch, > That is because the recent generations of web developers grew up (and > continue to grow up) with MySQL as the 'default' database, and thus > think it is perfectly normal to scatter their DDL/DML throughout the > source tree of their apps. This is what I am cleaning up in Joomla! > with the 1.2 release, which has been necessitated by the inclusion of > ADOdb (and therefore PostgreSQL and others). I cannot wait to get that > work started! :-D Great. You should also make plans to drop in PDO once 80% of your users are up to PHP5. ADODB is only an intermediate "driver". > I'm trying to convince the other Joomla! core developers to use > PostgreSQL as the standard reference/development platform, in order to > get closer to the SQL standards. If I end up writing any tutorial-type > stuff I will pass it along over here. Wish me luck ;-) OK, thanks. Also, please tell them that the folks on the #postgresql channel at irc.freenode.net are *very* helpful and available almost 24/7. Heck, we spend some time answering basic SQL questions for MySQL users, since they can't get help on the #mysql channel. > One thing for sure though - as both PHP matures as a technology, and > web developers also gain sophistication, PostgreSQL is uniquely > positioned as the one F/OSS database that will meet their needs. I see > a great opportunity here, and Oracle's purchase of Innobase - and the > resulting drama across the internet - will also push more web > developers towards PostgreSQL, even if only for evaluation. I certainly hope so. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Peter, > One normally doesn't use the extension .xhtml for XHTML files. > Using .html causes much less trouble. Augh. Well, they're in CVS now, I can't rename them. --Josh -- __Aglio Database Solutions_______________ Josh Berkus Consultant josh@agliodbs.com www.agliodbs.com Ph: 415-752-2500 Fax: 415-752-2387 2166 Hayes Suite 200 San Francisco, CA
On Mon, Oct 10, 2005 at 02:44:29PM -0300, Marc G. Fournier wrote: > On Mon, 10 Oct 2005, Jim C. Nasby wrote: > > >On Mon, Oct 10, 2005 at 07:19:47PM +0200, Peter Eisentraut wrote: > >>>- Many current MySQL users would like to adopt PostgreSQL but feel > >>>unable to do so because their application package does not support > >>>PostgreSQL at all/well enough or they feel there are technical issues > >>>with the MySQL to PostgreSQL code (not data) migration. > >> > >>And of course they are right. Porting from MySQL to PostgreSQL is a > >>problem, one which could only be solved by dumbing down PostgreSQL to > >>accept many of MySQL's idiosyncracies, which isn't going to happen. > > > >There are many features that could be implimented in PostgreSQL in a way > >that was both logical and supported MySQL converters, though. The recent > >discussion on one of the lists about adding enum as a type is an > >example. I'm sure there are others. > > > >I think the best way to increase migration from MySQL to PostgreSQL > >would be to find out what the biggest pains are for users attempting to > >migrate and then figure out how we can reduce that pain. In some cases > >these solutions might be adding features to PostgreSQL, but many of them > >might just involve improving existing migration tools. > > Couldn't these features be mostly added as a 'MySQL Compatibility add-on'? > For instance, the enum type you list above ... ? There's issues with doing that. I know one problem is that you currently can't pass parameters in when you define a column in a table, which you need to be able to do for an enum. But like I said, if we want to improve migration we should find out where the users have pain and concentrate on that. That was actually the context of the enum discussion. I threw enum out as an example and everyone latched onto it, missing the overall point of trying to improve migration from MySQL. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
I assume you know this, but you can always do mv blah.xhtml blah.html cvs remove blah.xhtml cvs add blah.html Of course with subversion you could just rename the file... On Mon, Oct 10, 2005 at 11:38:01AM -0700, Josh Berkus wrote: > Peter, > > > One normally doesn't use the extension .xhtml for XHTML files. > > Using .html causes much less trouble. > > Augh. Well, they're in CVS now, I can't rename them. > > --Josh > > -- > __Aglio Database Solutions_______________ > Josh Berkus Consultant > josh@agliodbs.com www.agliodbs.com > Ph: 415-752-2500 Fax: 415-752-2387 > 2166 Hayes Suite 200 San Francisco, CA > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Mon, Oct 10, 2005 at 02:42:43PM -0500, Jim C. Nasby wrote: > On Mon, Oct 10, 2005 at 02:44:29PM -0300, Marc G. Fournier wrote: > > On Mon, 10 Oct 2005, Jim C. Nasby wrote: > > > > >On Mon, Oct 10, 2005 at 07:19:47PM +0200, Peter Eisentraut wrote: > > >>>- Many current MySQL users would like to adopt PostgreSQL but > > >>>feel unable to do so because their application package does not > > >>>support PostgreSQL at all/well enough or they feel there are > > >>>technical issues with the MySQL to PostgreSQL code (not data) > > >>>migration. > > >> > > >>And of course they are right. Porting from MySQL to PostgreSQL > > >>is a problem, one which could only be solved by dumbing down > > >>PostgreSQL to accept many of MySQL's idiosyncracies, which isn't > > >>going to happen. > > > > > >There are many features that could be implimented in PostgreSQL > > >in a way that was both logical and supported MySQL converters, > > >though. The recent discussion on one of the lists about adding > > >enum as a type is an example. I'm sure there are others. > > > > > >I think the best way to increase migration from MySQL to > > >PostgreSQL would be to find out what the biggest pains are for > > >users attempting to migrate and then figure out how we can reduce > > >that pain. In some cases these solutions might be adding features > > >to PostgreSQL, but many of them might just involve improving > > >existing migration tools. > > > > Couldn't these features be mostly added as a 'MySQL Compatibility > > add-on'? For instance, the enum type you list above ... ? > > There's issues with doing that. I know one problem is that you > currently can't pass parameters in when you define a column in a > table, which you need to be able to do for an enum. In this case, it might be easier to make a writeable VIEW with two tables underneath and an appropriate call to ARRAY() and maybe to array_to_string() > But like I said, if we want to improve migration we should find out > where the users have pain and concentrate on that. Yes :) > That was actually the context of the enum discussion. I threw enum > out as an example and everyone latched onto it, missing the overall > point of trying to improve migration from MySQL. I didn't :) Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
On Mon, 10 Oct 2005, Jim C. Nasby wrote: > I assume you know this, but you can always do > > mv blah.xhtml blah.html > cvs remove blah.xhtml > cvs add blah.html Why not just do a 'mv blah.xhtml,v blah.html,v' in the repository itself, so that you don't lose any history? > > Of course with subversion you could just rename the file... > > On Mon, Oct 10, 2005 at 11:38:01AM -0700, Josh Berkus wrote: >> Peter, >> >>> One normally doesn't use the extension .xhtml for XHTML files. >>> Using .html causes much less trouble. >> >> Augh. Well, they're in CVS now, I can't rename them. >> >> --Josh >> >> -- >> __Aglio Database Solutions_______________ >> Josh Berkus Consultant >> josh@agliodbs.com www.agliodbs.com >> Ph: 415-752-2500 Fax: 415-752-2387 >> 2166 Hayes Suite 200 San Francisco, CA >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 2: Don't 'kill -9' the postmaster >> > > -- > Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com > Pervasive Software http://pervasive.com work: 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 > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 10 Oct 2005, David Fetter wrote: > In this case, it might be easier to make a writeable VIEW with two > tables underneath and an appropriate call to ARRAY() and maybe to > array_to_string() Is there any work being done on UPDATEABLE VIEWs? I found, at one point, a 'work around' for it, but just wondering if there is any work being done on a more 'native' method ... >> That was actually the context of the enum discussion. I threw enum >> out as an example and everyone latched onto it, missing the overall >> point of trying to improve migration from MySQL. > > I didn't :) I did, only as an example ... the question, on my part, being how many things could we 'mask', not so much focusing on enum itself :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 2005-10-10 at 14:10 -0400, Mitch Pirtle wrote: > I'm trying to convince the other Joomla! core developers to use > PostgreSQL as the standard reference/development platform, in order to > get closer to the SQL standards. If I end up writing any tutorial-type > stuff I will pass it along over here. Wish me luck ;-) I think its great that you can find the time to be on both groups. I'm sure many people don't. ISTM that we very much need to encourage and help cross-over advocates such as yourself. What help do you need from this project? What features do you need to succeed? ....probably best not to try to offload all at once, but please become an internal champion so that everybody can get your perspective on things and ensure the TODO list is well stocked. A part of getting people to adopt PostgreSQL is the feeling that they are personally catered for and are able to get their needs met. We need to get other projects to say "Hey, lets use PostgreSQL, they don't just make a good database, they listen to other projects". I'd like to think about adding further sections to the TODO list which group together sets of features with a particular focus. Items could be repeated (or linked to), to ensure we have the main TODO list as well as feature sets for particular user groups. Best Regards, Simon Riggs
On Mon, 2005-10-10 at 10:32 -0700, Josh Berkus wrote: > First off, Simon, could you look at the Press FAQ to see if there's > anything missing based on your experience at LWE-SF? > http://pgfoundry.org/docman/view.php/1000047/26/press_faq.xhtml The press FAQ says: Q: How does PostgreSQL compare to MySQL? A: This is a topic that can start several hours of discussion. As a quick summary, MySQL is the "popular, easy-to-use" database, and PostgreSQL is the "feature-rich, standards-compliant" database. Beyond that, each database user should make their own evaluation; open source software makes doing your own comparison very easy. General comments, not to Josh who does a thankless task well: The FAQ is correct, it does cause hours of discussion. This topic took approximately 6 man hours of detailed technical discussion. It also hits the nail on the head: how do you make your own comparison when you don't know what to look for? when you don't know enough about databases to try? It would be useful to have a link directly from the main PostgreSQL homepage to some information for the following: 1. how many awards PostgreSQL has won and what other people have said about the MySQL v PostgreSQL debate. 2. how we stack up against MySQL. If you don't say it, people think there's nothing to say 3. what replication solutions are available - "High Availability" IMHO you either say them yourself, or place yourself in the hands of a an average 3 minute search on Google. Nothing useful found => default answer of "they sound the same, lets go with the market leader". We don't need to go for weasel words, but a slowly developing section of direct competitive information is important. Maybe thousands of people will disagree with what is said there, but that doesn't stop it being worth saying by *this* project. I've got no axe to grind against MySQL, but the projects produce two distinct database systems with different objectives and use cases. Best Regards, Simon Riggs
On Mon, 2005-10-10 at 19:19 +0200, Peter Eisentraut wrote: > Simon Riggs wrote: > > - Many current MySQL users would like to adopt PostgreSQL but feel > > unable to do so because their application package does not support > > PostgreSQL at all/well enough or they feel there are technical issues > > with the MySQL to PostgreSQL code (not data) migration. > > And of course they are right. Porting from MySQL to PostgreSQL is a > problem, one which could only be solved by dumbing down PostgreSQL to > accept many of MySQL's idiosyncracies, which isn't going to happen. It does make me think that we should try to adopt some more of MySQL's idiosyntactics even if we don't fully adopt their idiosyncracies. Best Regards, Simon Riggs
Jim C. Nasby wrote: > Anyone else having trouble with that link? It's coming out as a blank > presentation for me. No trouble with the link itself, but the file I got was 0 bytes. Not a very useful flyer to hand to anyone ... ;-) -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 "Someone said that it is at least an order of magnitude more work to do production software than a prototype. I think he is wrong by at least an order of magnitude." (Brian Kernighan)
Simon, > > Anyone else having trouble with that link? It's coming out as a blank > > presentation for me. > > No trouble with the link itself, but the file I got was 0 bytes. Not a > very useful flyer to hand to anyone ... ;-) Looks like the ppt file got corrupted in the e-mail you sent me. Can you send another? -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Folks, > > And of course they are right. Porting from MySQL to PostgreSQL is a > > problem, one which could only be solved by dumbing down PostgreSQL to > > accept many of MySQL's idiosyncracies, which isn't going to happen. > > It does make me think that we should try to adopt some more of MySQL's > idiosyntactics even if we don't fully adopt their idiosyncracies. I really don't agree that the chief problem with porting from MySQL is our failure to implement ISNULL() or ENUM. I don't even think that's in the top 10. The biggest issues are: 1, 2, 3, and 4) Lack of information, e.g. no "PostgreSQL for MySQL users" handbook. 5) Flakyness of data migration tools, which are largely unmaintained these days; 6) Lack of data abstraction in many OSS apps (this we can't fix). -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Simon, > and now for the correct file. OK, re-uploaded. Please check. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
El Lun 10 Oct 2005 16:42, Jim C. Nasby escribió:
> >
> > Couldn't these features be mostly added as a 'MySQL Compatibility add-on'?
> > For instance, the enum type you list above ... ?
>
> There's issues with doing that. I know one problem is that you currently
> can't pass parameters in when you define a column in a table, which you
> need to be able to do for an enum.
>
> But like I said, if we want to improve migration we should find out
> where the users have pain and concentrate on that. That was actually the
> context of the enum discussion. I threw enum out as an example and
> everyone latched onto it, missing the overall point of trying to improve
> migration from MySQL.
The enum data type is just useless in most cases, and most MySQL programmers
use enum as a way to store booleans. Nothing more, and nothing less.
Just yeasterday somebody was asking about what to do with a field defined as
CHAR(2) loaded with 'Si' and 'No' (Yes and No in spanish). Ofcourse, when I
told him about boolean, and the posibility of easily transforming the bool
variable into a 'Si' or 'No' chain using CASE. Now the problem is that these
people don't know about the diferent data types, and what's worst, some don't
have a clue on good database design.
In my years of database programmer I have had to migrate a par of systems
working on MySQL, and I have to say that whenever I saw an enum data type, I
turned it to a boolean, and it allways would have been the best idea in the
first hand (ofcourse, the original programmer couldn't do so, as MySQL didn't
have the boolean data type).
I know that enum could be used in a lot of other ways, but for what I see,
everybody uses it as a replacement for boolean.
--
select 'mmarques' || '@' || 'unl.edu.ar' AS email;
---------------------------------------------------------
Martín Marqués | Programador, DBA
Centro de Telemática | Administrador
Universidad Nacional
del Litoral
---------------------------------------------------------
On Mon, 2005-10-10 at 14:56 -0700, Josh Berkus wrote: > > > Anyone else having trouble with that link? It's coming out as a blank > > > presentation for me. > > > > No trouble with the link itself, but the file I got was 0 bytes. Not a > > very useful flyer to hand to anyone ... ;-) > > Looks like the ppt file got corrupted in the e-mail you sent me. Can you > send another? OK, we're up now with a good file. Thanks for waiting. http://pgfoundry.org/docman/view.php/1000047/91/PostgreSQL_Flyer.ppt Best Regards, Simon Riggs
On Mon, Oct 10, 2005 at 11:56:38PM +0100, Simon Riggs wrote: > On Mon, 2005-10-10 at 14:56 -0700, Josh Berkus wrote: > > > > > Anyone else having trouble with that link? It's coming out as a blank > > > > presentation for me. > > > > > > No trouble with the link itself, but the file I got was 0 bytes. Not a > > > very useful flyer to hand to anyone ... ;-) > > > > Looks like the ppt file got corrupted in the e-mail you sent me. Can you > > send another? > > OK, we're up now with a good file. Thanks for waiting. > > http://pgfoundry.org/docman/view.php/1000047/91/PostgreSQL_Flyer.ppt How come it only mentions RPMs and the Windows installer? Seems like it would be better to just specify supported platforms, ie: PostgreSQL 8.0.4 is now available for Linux, most Unixes, OS X and Windows. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Mon, Oct 10, 2005 at 06:24:55PM -0300, Mart?n Marqu?s wrote: > El Lun 10 Oct 2005 16:42, Jim C. Nasby escribi?: > > > > > > Couldn't these features be mostly added as a 'MySQL Compatibility add-on'? > > > For instance, the enum type you list above ... ? > > > > There's issues with doing that. I know one problem is that you currently > > can't pass parameters in when you define a column in a table, which you > > need to be able to do for an enum. > > > > But like I said, if we want to improve migration we should find out > > where the users have pain and concentrate on that. That was actually the > > context of the enum discussion. I threw enum out as an example and > > everyone latched onto it, missing the overall point of trying to improve > > migration from MySQL. > > The enum data type is just useless in most cases, and most MySQL programmers > use enum as a way to store booleans. Nothing more, and nothing less. > > Just yeasterday somebody was asking about what to do with a field defined as > CHAR(2) loaded with 'Si' and 'No' (Yes and No in spanish). Ofcourse, when I > told him about boolean, and the posibility of easily transforming the bool > variable into a 'Si' or 'No' chain using CASE. Now the problem is that these > people don't know about the diferent data types, and what's worst, some don't > have a clue on good database design. > > In my years of database programmer I have had to migrate a par of systems > working on MySQL, and I have to say that whenever I saw an enum data type, I > turned it to a boolean, and it allways would have been the best idea in the > first hand (ofcourse, the original programmer couldn't do so, as MySQL didn't > have the boolean data type). > > I know that enum could be used in a lot of other ways, but for what I see, > everybody uses it as a replacement for boolean. Interesting, though Bugzilla used it for a bunch of stuff until they decided to support databases other than MySQL. The plan is to eventually just store an int that points back to a parent table (ie: the right way to do it...) -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Mon, Oct 10, 2005 at 03:07:26PM -0700, Josh Berkus wrote: > Folks, > > > > And of course they are right. ??Porting from MySQL to PostgreSQL is a > > > problem, one which could only be solved by dumbing down PostgreSQL to > > > accept many of MySQL's idiosyncracies, which isn't going to happen. > > > > It does make me think that we should try to adopt some more of MySQL's > > idiosyntactics even if we don't fully adopt their idiosyncracies. > > I really don't agree that the chief problem with porting from MySQL is our > failure to implement ISNULL() or ENUM. I don't even think that's in the > top 10. > > The biggest issues are: > 1, 2, 3, and 4) Lack of information, e.g. no "PostgreSQL for MySQL users" > handbook. > 5) Flakyness of data migration tools, which are largely unmaintained these > days; > 6) Lack of data abstraction in many OSS apps (this we can't fix). Well, 1-4 and 6 are all tied together: lack of information (and in some cases exposure to that info). -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Mon, Oct 10, 2005 at 05:42:31PM -0300, Marc G. Fournier wrote: > On Mon, 10 Oct 2005, David Fetter wrote: > > >In this case, it might be easier to make a writeable VIEW with two > >tables underneath and an appropriate call to ARRAY() and maybe to > >array_to_string() > > Is there any work being done on UPDATEABLE VIEWs? I found, at one point, > a 'work around' for it, but just wondering if there is any work being done > on a more 'native' method ... We have updateable views if you write the rules for them. A default updateable view could only be accurate all the time if it only contained a single table reference. Our technique is more flexible and powerful, but scarier due to RULES being scary. There are documents on this, however, and the rules are quite simple if the developer knows what they want done when the view is updated. --elein > > >>That was actually the context of the enum discussion. I threw enum > >>out as an example and everyone latched onto it, missing the overall > >>point of trying to improve migration from MySQL. > > > >I didn't :) > > I did, only as an example ... the question, on my part, being how many > things could we 'mask', not so much focusing on enum itself :) > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
On Mon, Oct 10, 2005 at 05:05:46PM -0700, elein wrote: > On Mon, Oct 10, 2005 at 05:42:31PM -0300, Marc G. Fournier wrote: > > On Mon, 10 Oct 2005, David Fetter wrote: > > > > >In this case, it might be easier to make a writeable VIEW with two > > >tables underneath and an appropriate call to ARRAY() and maybe to > > >array_to_string() > > > > Is there any work being done on UPDATEABLE VIEWs? I found, at one point, > > a 'work around' for it, but just wondering if there is any work being done > > on a more 'native' method ... > > We have updateable views if you write the rules for them. > A default updateable view could only be accurate all the > time if it only contained a single table reference. Our Well, you can create multi-table views that are also updateable. IIRC the restriction is that joins must all be inner joins and you can't be doing any kind of group by. I know the DB2 docs talk about this and I'm pretty sure Oracle's do as well. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Mon, Oct 10, 2005 at 07:18:01PM -0500, Jim C. Nasby wrote: > On Mon, Oct 10, 2005 at 05:05:46PM -0700, elein wrote: > > On Mon, Oct 10, 2005 at 05:42:31PM -0300, Marc G. Fournier wrote: > > > On Mon, 10 Oct 2005, David Fetter wrote: > > > > > > >In this case, it might be easier to make a writeable VIEW with two > > > >tables underneath and an appropriate call to ARRAY() and maybe to > > > >array_to_string() > > > > > > Is there any work being done on UPDATEABLE VIEWs? I found, at one point, > > > a 'work around' for it, but just wondering if there is any work being done > > > on a more 'native' method ... > > > > We have updateable views if you write the rules for them. > > A default updateable view could only be accurate all the > > time if it only contained a single table reference. Our > > Well, you can create multi-table views that are also updateable. IIRC > the restriction is that joins must all be inner joins and you can't be > doing any kind of group by. I know the DB2 docs talk about this and I'm > pretty sure Oracle's do as well. You can start adding the "yeah, buts" which only makes it more confusing. That is why I said "accurate ALL the time". --elein > -- > Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com > Pervasive Software http://pervasive.com work: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq >
> I think the best way to increase migration from MySQL to PostgreSQL > would be to find out what the biggest pains are for users attempting to > migrate and then figure out how we can reduce that pain. In some cases > these solutions might be adding features to PostgreSQL, but many of them > might just involve improving existing migration tools. I think we as a team need to start working on a complete migration tool suite... Chris
>>And of course they are right. Porting from MySQL to PostgreSQL is a >>problem, one which could only be solved by dumbing down PostgreSQL to >>accept many of MySQL's idiosyncracies, which isn't going to happen. > > > It does make me think that we should try to adopt some more of MySQL's > idiosyntactics even if we don't fully adopt their idiosyncracies. Yes, especially since THEY make an effort to support US :) They now even support SERIAL as a pseudo-type :) Chris
Am Montag, 10. Oktober 2005 22:42 schrieb Marc G. Fournier: > Is there any work being done on UPDATEABLE VIEWs? Yes. -- Peter Eisentraut http://developer.postgresql.org/~petere/
> Am Montag, 10. Oktober 2005 22:42 schrieb Marc G. Fournier: > >>Is there any work being done on UPDATEABLE VIEWs? > > > Yes. Who's doing it? Chris
On Mon, 2005-10-10 at 18:23 -0500, Jim C. Nasby wrote: > On Mon, Oct 10, 2005 at 11:56:38PM +0100, Simon Riggs wrote: > > http://pgfoundry.org/docman/view.php/1000047/91/PostgreSQL_Flyer.ppt > > How come it only mentions RPMs and the Windows installer? Seems like it > would be better to just specify supported platforms, ie: Those are the only ones available for immediate binary download > PostgreSQL 8.0.4 is now available for Linux, most Unixes, OS X and > Windows. The back of the flyer says that. Best Regards, Simon Riggs
Am Dienstag, 11. Oktober 2005 08:40 schrieb Christopher Kings-Lynne: > > Am Montag, 10. Oktober 2005 22:42 schrieb Marc G. Fournier: > >>Is there any work being done on UPDATEABLE VIEWs? > > > > Yes. > > Who's doing it? Bernd Helme and Jaime Casanova. Patches are available and have regularly been posted. A bit of encouragement and hand-holding will be necessary to finish the work. -- Peter Eisentraut http://developer.postgresql.org/~petere/
elein wrote: > On Mon, Oct 10, 2005 at 07:18:01PM -0500, Jim C. Nasby wrote: >> On Mon, Oct 10, 2005 at 05:05:46PM -0700, elein wrote: >>> On Mon, Oct 10, 2005 at 05:42:31PM -0300, Marc G. Fournier wrote: >>>> On Mon, 10 Oct 2005, David Fetter wrote: >>>> >>>>> In this case, it might be easier to make a writeable VIEW with two >>>>> tables underneath and an appropriate call to ARRAY() and maybe to >>>>> array_to_string() >>>> Is there any work being done on UPDATEABLE VIEWs? I found, at one point, >>>> a 'work around' for it, but just wondering if there is any work being done >>>> on a more 'native' method ... >>> We have updateable views if you write the rules for them. >>> A default updateable view could only be accurate all the >>> time if it only contained a single table reference. Our >> Well, you can create multi-table views that are also updateable. IIRC >> the restriction is that joins must all be inner joins and you can't be >> doing any kind of group by. I know the DB2 docs talk about this and I'm >> pretty sure Oracle's do as well. > > You can start adding the "yeah, buts" which only makes it more > confusing. That is why I said "accurate ALL the time". You can decide from a view's definition (and those of the tables / functions it uses) whether it will be one of: 1. Updatable unambiguously (single table, some inner-join) 2. Updatable given some additional rules (most non-aggregate) 3. Not updatable (any aggregate view) The main issue is "for the view row I want to update/insert, can I identify the relevant key(s) for the underlying table(s)". -- Richard Huxton Archonet Ltd
Greetings, I usualy lurk but I have an idea here: On Mon, 10 Oct 2005, Simon Riggs wrote: > to get other projects to say "Hey, lets use PostgreSQL, they don't just > make a good database, they listen to other projects". Something else that would encourage adoption: the ability for a project to become part of a Total Solution. I just proposed an article to Linux Journal about this yesterday. Basically, the more projects that use PostgreSQL, the more those projects can talk to each other. Here's an example: I am working on a project called LibreLex; basically, it's a complete OSS law office. I took a web-based GPL'd Law Office app (Knomos) and I am converting it from MySQL to PG. Once that is done, I will integrate it with Quasar Accounting - a GPL'd accounting application that uses PG as a backend. How will this integration work? I plan to create a set of triggers on the Knomos tables so that when they are updated, the Quasar tables are updated accordingly; so, for instance, when a lawyer records an event on his timesheet, this event will automatically propagate to the client's current invoice in Quasar. There are a number of other apps that could be combined in such a fashion: SugarCRM, Quasar Accounting, Open Realty, Knomos are just a few. Microsoft is touting "deep integration" of its office software so that there is no duplication of effort; data entered in one app will move to all affected apps. Consultants (or anyone else) using these kinds of mature Open Source apps can also have this kind of integration with a little bit of work - surely less work than the comparable Microsoft solution would cost in licensing. Integration is a way that OSS can be very competitive against Microsoft; and PostgreSQL is a way to achieve that integration. Thoughts? --Josh Resources: http://www.librelex.net http://www.linuxcanada.com http://www.knomos.org
Josh Berkus wrote: > Peter, Simon: > > First off, Simon, could you look at the Press FAQ to see if there's > anything missing based on your experience at LWE-SF? > http://pgfoundry.org/docman/view.php/1000047/26/press_faq.xhtml > > >>And of course they are right. Porting from MySQL to PostgreSQL is a >>problem, one which could only be solved by dumbing down PostgreSQL to >>accept many of MySQL's idiosyncracies, which isn't going to happen. > > > Well, better migration tools would be a start. PHP's gradual transition to > PDO (and working with the PDO folks to make PDO_pgsql better, like not > doing count(*)) will help a lot too; the biggest MySQL migration > complaints I here are from users of PHP stuff like *Nuke and various Wikis > which sprinkle SQL throughout the interface code. > > More important than any of these would be a 5-page guide, "Migration Tips > from MySQL to PostgreSQL." I have laying next to me 7+ page article from the October 2003 issue of phpArchitect. "Migrating from MySQL to PostgreSQL" by Rick Morris. I only got a copy so I could help the php users at my old job move over and I only scanned it at the time. Just rediscovered it this AM. Serendipity? Two other things come to mind since I just started a job that uses MySQL. 1. I still haven't (re)searched for a substitute for MySQL Browser that they find indispensable. Off the top of anyone's head is there a similar tool? 2. I have made a lot of head way towards a move from MySQL because of triggers and rules, and multiple languages to write them in ( get this stuff out of the code.) I will be following this closely and may be able to help when I finally get my way and we move on. I've already got several MySQL-isms in the code headed out the door. Rod -- --- [Certified Virus free by ASISNA Mail Services. www.asisna.com ]
Roderick A. Anderson wrote: > 1. I still haven't (re)searched for a substitute for MySQL Browser that > they find indispensable. Off the top of anyone's head is there a > similar tool? Off the top of the postgresql download page: how about phppgadmin or pgAdmin III? Regards, Andreas
Joshua, > I am working on a project called LibreLex; basically, it's a complete > OSS law office. I took a web-based GPL'd Law Office app (Knomos) and I > am converting it from MySQL to PG. Once that is done, I will integrate > it with Quasar Accounting - a GPL'd accounting application that uses PG > as a backend. How will this integration work? I plan to create a set > of triggers on the Knomos tables so that when they are updated, the > Quasar tables are updated accordingly; so, for instance, when a lawyer > records an event on his timesheet, this event will automatically > propagate to the client's current invoice in Quasar. Feel free to bounce ideas off me; I've written several legal apps in my time (document coding, settlement accounting, case/calendar management). I'm on irc.freenode.net and on AIM as "agliodbs". UDFs are key for case management. > Integration is a way that OSS can be very competitive against Microsoft; > and PostgreSQL is a way to achieve that integration. Yes ... that's why the Bizgres project is working on integrating PG, KETL, JasperSoft and OpenI into one "stack". --Josh
Andreas Pflug wrote: > Roderick A. Anderson wrote: > >> 1. I still haven't (re)searched for a substitute for MySQL Browser >> that they find indispensable. Off the top of anyone's head is there a >> similar tool? > > > Off the top of the postgresql download page: how about phppgadmin or > pgAdmin III? That's the ticket. I looked at pgAdmin III a few months ago but only had a 7.2 install to test/try it against. A no go there. The one place I didn't look -- Downloads. Was there a discussion of specific link to the tools a few months ago? Rod -- --- [Certified Virus free by ASISNA Mail Services. www.asisna.com ]
> That's the ticket. I looked at pgAdmin III a few months ago but only > had a 7.2 install to test/try it against. A no go there. phpPgAdmin will run against 7.2, but of course it's web-based... Chris
On Mon, Oct 10, 2005 at 12:27:22PM -0500, Jim C. Nasby wrote:
> I think the best way to increase migration from MySQL to PostgreSQL
> would be to find out what the biggest pains are for users attempting to
> migrate and then figure out how we can reduce that pain. In some cases
> these solutions might be adding features to PostgreSQL, but many of them
> might just involve improving existing migration tools.
Well, here's my top of the head list from an RT migration we did. I
don't have my notes handy; this is from memory. Note that most of
the problems came from SearchBuilder, which is what RT uses as an
abstraction layer. See the bottom of this for my "real problem"
analysis.
1. Case insensitivity. You can work around this, of course, but
it is _tedious_.
2. SELECT count(*) is slow. I know, I know.
3. Really huge OR sets pick the wrong plan. My bet is that this
could be tuned away, but it's tough to argue for this when MySQL did
it fast.
4. UNIX domain sockets are _way_ faster than TCP/IP; the same
penalty appears not to be there for MySQL.
5. Developers think in MySQL.
IMO, (5) is the real problem. An application which was,
fundamentally, designed around the SQL-filesystem that is MySQL 3.x
is never really going to use the database in an effective way; and
that likely means that migration is always going to be a very painful
problem.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
A certain description of men are for getting out of debt, yet are
against all taxes for raising money to pay it off.
--Alexander Hamilton
On Mon, Oct 10, 2005 at 03:07:26PM -0700, Josh Berkus wrote:
> The biggest issues are:
> 1, 2, 3, and 4) Lack of information, e.g. no "PostgreSQL for MySQL users"
> handbook.
> 5) Flakyness of data migration tools, which are largely unmaintained these
> days;
> 6) Lack of data abstraction in many OSS apps (this we can't fix).
As I suggested in another mail in this thread, I suspect that 6 is
actually item 0 here.
I've mentioned before the conversations I've had in the halls and at
the booth at OSCON, but I'll say it again: I've had a lot of "power"
MySQL users tell me, "Why would I move to Postgres? MySQL has
everything I need; the licenses are cheap; and, when I _really_ need
big iron, I go get Oracle, because the clients will pay anyway, since
they're buying expensive hardware."
I think MySQL is indeed perceived by some as "our competition",
because they have two classes: "Open source databases" and "Real
databases." In my opinion, the MySQL space isn't interesting: most
of the systems are not really database-backed systems at all, but are
systems that sort of look databasey. When you look at the code,
there are all sorts of horrible things that no-one familiar with
normalisation or constraints would ever do; but that's what
inexperience has bred. And the truth is that those applications are
_always_ going to have pain when they need to migrate to a real
system, because the problem isn't the storage engine or the lack of
ACID or anything like that, but the total absense of a real data
model.
So we need to focus on moving out to the "Open source databases"
category and into the "Real databases" category. One way to do this,
of course, is to tell people that if they only think they need MySQL,
they should go there; we're really for people who need a system like
Oracle or DB2, except that we're free. If enough people believe
that, new projects who would have used MySQL will use Postgres
instead.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
Information security isn't a technological problem. It's an economics
problem.
--Bruce Schneier