Re: pg_dump bug fixing
От | Christopher Kings-Lynne |
---|---|
Тема | Re: pg_dump bug fixing |
Дата | |
Msg-id | 411040EC.8040307@familyhealth.com.au обсуждение исходный текст |
Ответ на | Re: pg_dump bug fixing (Josh Berkus <josh@agliodbs.com>) |
Список | 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 по дате отправления: