Remove MySQL Tools from Source?

Josh Berkus <josh@agliodbs.com> writes:

I'm thinking it's time to remove the "MySQL" conversion tools from the
PostgreSQL source tree and put them somewhere they might be maintained.
I've just done some testing, and neither one works with current versions of
MySQLdump.

Hmm ... seems like the big question is not "where to keep them" but
"who's gonna maintain them" ... without active maintenance they're
just dead bits wherever they're stored, because MySQL and Postgres
are both moving targets.

These tools are a not insignificant part of our Plan for World
Domination ;-) so it would be good if somebody stepped up to the
plate and volunteered to take care of 'em. Anybody?

regards, tom lane

Tom,

Hmm ... seems like the big question is not "where to keep them" but
"who's gonna maintain them" ... without active maintenance they're
just dead bits wherever they're stored, because MySQL and Postgres
are both moving targets.

These tools are a not insignificant part of our Plan for World
Domination ;-) so it would be good if somebody stepped up to the
plate and volunteered to take care of 'em. Anybody?

Well, I'm planning on updating my2pg. Of the 3 packages available (one from
Thomas Lockhart, one from Donna Pavlusinc, and my2pg, originally from Max
Rudensky), it is the most functional. That's kind of a shame, since the Perl
is pretty sloppy, but it does work.

I'd be happy to take the lead as maintainer of my2pg. But, I want to move it
to pgFoundry (due for launch as soon as I get my other 10 super-urgent tasks
out of the way) , and take it out of /contrib. I feel pretty strongly
that it will be more visible and easier to maintain on its own than in
/contrib.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus wrote:

Tom,

Hmm ... seems like the big question is not "where to keep them" but
"who's gonna maintain them" ... without active maintenance they're
just dead bits wherever they're stored, because MySQL and Postgres
are both moving targets.

These tools are a not insignificant part of our Plan for World
Domination ;-) so it would be good if somebody stepped up to the
plate and volunteered to take care of 'em. Anybody?

Well, I'm planning on updating my2pg. Of the 3 packages available (one from
Thomas Lockhart, one from Donna Pavlusinc, and my2pg, originally from Max
Rudensky), it is the most functional. That's kind of a shame, since the Perl
is pretty sloppy, but it does work.

I'd be happy to take the lead as maintainer of my2pg. But, I want to move it
to pgFoundry (due for launch as soon as I get my other 10 super-urgent tasks
out of the way) , and take it out of /contrib. I feel pretty strongly
that it will be more visible and easier to maintain on its own than in
/contrib.

And what to do with the other db conversion tools? Seems they should be
kept together.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce,

And what to do with the other db conversion tools? Seems they should be
kept together.

... on projects.postgresql.org, or similar. They really aren't doing any
good in /contrib.

I've already set up a category "conversion tools" on pgFoundry, and my idea
was one project per target system.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

On Wed, 14 Apr 2004, Bruce Momjian wrote:

I'd be happy to take the lead as maintainer of my2pg. But, I want to move it
to pgFoundry (due for launch as soon as I get my other 10 super-urgent tasks
out of the way) , and take it out of /contrib. I feel pretty strongly
that it will be more visible and easier to maintain on its own than in
/contrib.

And what to do with the other db conversion tools? Seems they should be
kept together.

Make a 'data conversion' category on projects?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:

On Wed, 14 Apr 2004, Bruce Momjian wrote:

I'd be happy to take the lead as maintainer of my2pg. But, I want to move it
to pgFoundry (due for launch as soon as I get my other 10 super-urgent tasks
out of the way) , and take it out of /contrib. I feel pretty strongly
that it will be more visible and easier to maintain on its own than in
/contrib.

And what to do with the other db conversion tools? Seems they should be
kept together.

Make a 'data conversion' category on projects?

Yea.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Josh Berkus <josh@agliodbs.com> writes:

And what to do with the other db conversion tools? Seems they should be
kept together.

... on projects.postgresql.org, or similar. They really aren't doing any
good in /contrib.

Fair enough. They're not tightly tied to the backend, so I see no
strong reason to keep 'em in contrib rather than as independent
projects.

regards, tom lane

... on projects.postgresql.org, or similar. They really aren't doing any
good in /contrib.

I've already set up a category "conversion tools" on pgFoundry, and my idea
was one project per target system.

I reckon that by far the best way to do a mysql2pgsql converter is to
just modify mysqldump C source code to output in postgresql format!

Chris

El Mié 14 Abr 2004 22:22, Christopher Kings-Lynne escribió:

... on projects.postgresql.org, or similar. They really aren't doing
any good in /contrib.

I've already set up a category "conversion tools" on pgFoundry, and my
idea was one project per target system.

I reckon that by far the best way to do a mysql2pgsql converter is to
just modify mysqldump C source code to output in postgresql format!

I always ran one of the 2 scripts (can't remember which one) and after that
started checking the dump file, because there were things that didn't get
changed correctly[1]I always remember the first conversion I did. I found out that MySQL accepted dates like 30/2/2000 or 0-0-0000. Very odd..

[1]: I always remember the first conversion I did. I found out that MySQL accepted dates like 30/2/2000 or 0-0-0000. Very odd.
accepted dates like 30/2/2000 or 0-0-0000.
Very odd.

--
08:24:01 up 37 days, 12:51, 2 users, load average: 0.91, 0.85, 0.98
-----------------------------------------------------------------
Martín Marqués | select 'mmarques' || '@' || 'unl.edu.ar'
Centro de Telematica | DBA, Programador, Administrador
Universidad Nacional
del Litoral
-----------------------------------------------------------------

How to unsobscreve from this list?

TIA

I always ran one of the 2 scripts (can't remember which one) and after that
started checking the dump file, because there were things that didn't get
changed correctly[1].

[1]: I always remember the first conversion I did. I found out that MySQL
accepted dates like 30/2/2000 or 0-0-0000.
Very odd.

Yes, MySQL has always accepted those as perfectly valid dates. It's
quite broken.

Chris

On Fri, 16 Apr 2004, Christopher Kings-Lynne wrote:

I always ran one of the 2 scripts (can't remember which one) and after that
started checking the dump file, because there were things that didn't get
changed correctly[1].

[1]: I always remember the first conversion I did. I found out that MySQL
accepted dates like 30/2/2000 or 0-0-0000.
Very odd.

Yes, MySQL has always accepted those as perfectly valid dates. It's
quite broken.

the sad thing is that while MySQL implemented a -ansi switch that
supposedly turns on ansi compliance, it only fixes about 1/2 of all the
non-compliance issues. Yet another half-implemented feature... :)

Scott,

the sad thing is that while MySQL implemented a -ansi switch that
supposedly turns on ansi compliance, it only fixes about 1/2 of all the
non-compliance issues. Yet another half-implemented feature... :)

Plus they completely broke ansi-compliance with the latest version of
mysqldump, which is what I'm struggling with. To quote one of the
developers on #mysql:
"Oh, that's not really a bug, it only affects ANSI mode".

However, Perl is superb at pattern-matching, so I've patched for it ...

--
-Josh Berkus
Aglio Database Solutions
San Francisco

Christopher Kings-Lynne wrote:

... on projects.postgresql.org, or similar. They really aren't
doing any good in /contrib.

I've already set up a category "conversion tools" on pgFoundry, and
my idea was one project per target system.

I reckon that by far the best way to do a mysql2pgsql converter is to
just modify mysqldump C source code to output in postgresql format!

... and contribute it to MySQL :-)

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Jan Wieck wrote:

Christopher Kings-Lynne wrote:

... on projects.postgresql.org, or similar. They really aren't
doing any good in /contrib.

I've already set up a category "conversion tools" on pgFoundry, and
my idea was one project per target system.

I reckon that by far the best way to do a mysql2pgsql converter is to
just modify mysqldump C source code to output in postgresql format!

... and contribute it to MySQL :-)

But you would have to assign the copyright to them ....

If someone is going to make money from my code, I prefer it to be me, or
at least that everyone has a chance to do so rather than just one company.

cheers

andrew

But you would have to assign the copyright to them ....

If someone is going to make money from my code, I prefer it to be me, or
at least that everyone has a chance to do so rather than just one company.

Well, then for the same reason we should write a Perl script that
connects to MySQl and dumps in PGSql format.

I think it's silly to try and read a MySQL dump and convert it - let's
just dump straight from the source.

Josh - I'm kind of keen to make this happen...

Chris

Christopher Kings-Lynne said:

But you would have to assign the copyright to them ....

If someone is going to make money from my code, I prefer it to be me,
or at least that everyone has a chance to do so rather than just one
company.

Well, then for the same reason we should write a Perl script that
connects to MySQl and dumps in PGSql format.

I think it's silly to try and read a MySQL dump and convert it - let's
just dump straight from the source.

Josh - I'm kind of keen to make this happen...

You might want to check out the DBIx::DB_Schema module at
http://search.cpan.org/~ivan/DBIx-DBSchema-0.23/DBSchema.pm

cheers

andrew

Tom Lane wrote:

These tools are a not insignificant part of our Plan for World
Domination ;-) so it would be good if somebody stepped up to the
plate and volunteered to take care of 'em. Anybody?

Which brings me to another question

I have a bunch of perl scripts, as well as one user-defined type, for
porting from SQL Server. Where should I place these?

Inside the PG source seems....wrong. Then again, gborg does not seem to
be accepting new projects at the moment. I can put them on
sourceforge/berlios etc, and ask for a link, if you like.

Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/

Shachar Shemesh wrote:

Tom Lane wrote:

These tools are a not insignificant part of our Plan for World
Domination ;-) so it would be good if somebody stepped up to the
plate and volunteered to take care of 'em. Anybody?

Which brings me to another question

I have a bunch of perl scripts, as well as one user-defined type, for
porting from SQL Server. Where should I place these?

Inside the PG source seems....wrong. Then again, gborg does not seem
to be accepting new projects at the moment. I can put them on
sourceforge/berlios etc, and ask for a link, if you like.

The replacement for gborg should be available within a few days.

cheers

andrew

Andrew Dunstan wrote:

Christopher Kings-Lynne said:

But you would have to assign the copyright to them ....

If someone is going to make money from my code, I prefer it to be me,
or at least that everyone has a chance to do so rather than just one
company.

Well, then for the same reason we should write a Perl script that
connects to MySQl and dumps in PGSql format.

I think it's silly to try and read a MySQL dump and convert it - let's
just dump straight from the source.

Josh - I'm kind of keen to make this happen...

You might want to check out the DBIx::DB_Schema module at
http://search.cpan.org/~ivan/DBIx-DBSchema-0.23/DBSchema.pm

And this also looks cool - I just came across it searching for something
else:

http://sqlfairy.sourceforge.net/

cheers

andrew

Shachar,

I have a bunch of perl scripts, as well as one user-defined type, for
porting from SQL Server. Where should I place these?

Give us a few days. We'll be announcing the opening of the new projects site
soon (like, wednesday).

Regrettably, the perfect feature for this sort of thing, GForge's Code
Snippets, has a bug that will prevent us from using it immediately. But
I'll see what I can do.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Andrew Dunstan wrote:

Jan Wieck wrote:

Christopher Kings-Lynne wrote:

... on projects.postgresql.org, or similar. They really aren't
doing any good in /contrib.

I've already set up a category "conversion tools" on pgFoundry, and
my idea was one project per target system.

I reckon that by far the best way to do a mysql2pgsql converter is to
just modify mysqldump C source code to output in postgresql format!

... and contribute it to MySQL :-)

But you would have to assign the copyright to them ....

If someone is going to make money from my code, I prefer it to be me, or
at least that everyone has a chance to do so rather than just one company.

You still don't understand their business model. You publish the code
under GPL for free, and offer it under something else for sale for
everyone who's actually stupid enough to use it.

Jan

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #