From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_dump bug fixing |
Date: | 2004-08-04 01:50:36 |
Message-ID: | 411040EC.8040307@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2004-08-04 01:55:42 | Re: Anybody have an Oracle PL/SQL reference at hand? |
Previous Message | Christopher Kings-Lynne | 2004-08-04 01:46:22 | Re: Anybody have an Oracle PL/SQL reference at hand? |