Thread: Re: [HACKERS] 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
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
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
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].
[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.
--
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 #