Re: pg_dump bug fixing - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject Re: pg_dump bug fixing
Date
Msg-id 411040EC.8040307@familyhealth.com.au
Whole thread Raw
In response to Re: pg_dump bug fixing  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
> I'm not really keen on this idea unless you're eager to make a 5-year 
> commitment to maintain the code.   The load formats of other RDBMSes change 
> all the time -- MySQL is a particularly egregious example, with 2 
> incompatible changes in the last year -- and it would become a pain to keep 
> track.   

Well, I could do it on pgfoundry, but it would really suck to have to 
dupe all the pg_dump code.  Maybe I will have to.

> More to the point, there are a number of 3rd-party OSS and proprietary 
> utilities which can do this kind of format conversion.   For example, Perl 
> DB::Interpolator will cover PG, MySQL, Oracle and MSSQL once that 
> functionality is out of beta.

Do they convert the sql dumps or dump from the backend?  I really, 
really want to make a mysql2pgsql converter that doesn't really on text 
file parsing.  Modifying mysqldump would be easiest, but the problem is 
licensing I think...

> I can see, though, having a --strict-sql switch for pg_dump which would dump 
> all database objects in strict SQL92, which should be pretty compatible with 
> other systems.   This should also be easier to implement and trivial to 
> maintain.  Though it would mean not dumping functions and doing a few data 
> type conversions.

Yeah, perhaps.  And issuing a log of warnings so you can see what 
information you've lost.

Chris



pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: Anybody have an Oracle PL/SQL reference at hand?
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: Anybody have an Oracle PL/SQL reference at hand?