Обсуждение: Feedback from LinuxWorld, London

Поиск
Список
Период
Сортировка

Feedback from LinuxWorld, London

От
Simon Riggs
Дата:
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



Re: Feedback from LinuxWorld, London

От
"Jim C. Nasby"
Дата:
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

Re: Feedback from LinuxWorld, London

От
Peter Eisentraut
Дата:
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/

Re: Feedback from LinuxWorld, London

От
"Jim C. Nasby"
Дата:
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

Re: Feedback from LinuxWorld, London

От
Josh Berkus
Дата:
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

Re: Feedback from LinuxWorld, London

От
"Marc G. Fournier"
Дата:
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

Re: Feedback from LinuxWorld, London

От
Mitch Pirtle
Дата:
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

Re: Feedback from LinuxWorld, London

От
Josh Berkus
Дата:
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

Re: Feedback from LinuxWorld, London

От
Josh Berkus
Дата:
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

Re: Feedback from LinuxWorld, London

От
"Jim C. Nasby"
Дата:
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

Re: Feedback from LinuxWorld, London

От
"Jim C. Nasby"
Дата:
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

Re: Feedback from LinuxWorld, London

От
David Fetter
Дата:
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!

Re: Feedback from LinuxWorld, London

От
"Marc G. Fournier"
Дата:
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

Re: Feedback from LinuxWorld, London

От
"Marc G. Fournier"
Дата:
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

Re: Feedback from LinuxWorld, London

От
Simon Riggs
Дата:
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


Re: Feedback from LinuxWorld, London

От
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


Re: Feedback from LinuxWorld, London

От
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


Re: Feedback from LinuxWorld, London

От
Alvaro Herrera
Дата:
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)

Re: Feedback from LinuxWorld, London

От
Josh Berkus
Дата:
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

Re: Feedback from LinuxWorld, London

От
Josh Berkus
Дата:
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

Re: Feedback from LinuxWorld, London

От
Josh Berkus
Дата:
Simon,

> and now for the correct file.

OK, re-uploaded.  Please check.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

Re: Feedback from LinuxWorld, London

От
Martín Marqués
Дата:
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
---------------------------------------------------------

Re: Feedback from LinuxWorld, London

От
Simon Riggs
Дата:
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


Re: Feedback from LinuxWorld, London

От
"Jim C. Nasby"
Дата:
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

Re: Feedback from LinuxWorld, London

От
"Jim C. Nasby"
Дата:
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

Re: Feedback from LinuxWorld, London

От
"Jim C. Nasby"
Дата:
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

Re: Feedback from LinuxWorld, London

От
elein
Дата:
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
>

Re: Feedback from LinuxWorld, London

От
"Jim C. Nasby"
Дата:
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

Re: Feedback from LinuxWorld, London

От
elein
Дата:
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
>

Re: Feedback from LinuxWorld, London

От
Christopher Kings-Lynne
Дата:
> 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


Re: Feedback from LinuxWorld, London

От
Christopher Kings-Lynne
Дата:
>>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


Re: Feedback from LinuxWorld, London

От
Peter Eisentraut
Дата:
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/

Re: Feedback from LinuxWorld, London

От
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?

Chris


Re: Feedback from LinuxWorld, London

От
Simon Riggs
Дата:
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


Re: Feedback from LinuxWorld, London

От
Peter Eisentraut
Дата:
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/

Re: Feedback from LinuxWorld, London

От
Richard Huxton
Дата:
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

Thoughts Regarding Integration (was Re: Feedback from LinuxWorld, London)

От
Joshua Kramer
Дата:
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


Re: Feedback from LinuxWorld, London

От
"Roderick A. Anderson"
Дата:
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 ]


Re: Feedback from LinuxWorld, London

От
Andreas Pflug
Дата:
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

Re: Thoughts Regarding Integration (was Re: Feedback

От
Josh Berkus
Дата:
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

Re: Feedback from LinuxWorld, London

От
"Roderick A. Anderson"
Дата:
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 ]


Re: Feedback from LinuxWorld, London

От
Christopher Kings-Lynne
Дата:
> 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


Re: Feedback from LinuxWorld, London

От
Andrew Sullivan
Дата:
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

Re: Feedback from LinuxWorld, London

От
Andrew Sullivan
Дата:
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