Re: [Spacewalk-devel] MySQL porting info

2009-04-28 Thread Tom Lane
=?ISO-8859-2?Q?Miroslav_Such=FD?= writes: > The plan is to make database proxy, where Spacewalk will connect to this > db proxy, which will transform queries in runtime and then will handle > them to mysql, get the data and pass it back to Spacewalk Oh, so this is a research project rather than

Re: [Spacewalk-devel] MySQL porting info

2009-04-28 Thread Miroslav Suchý
Tom Lane wrote: The usual experience AFAIR is that the queries have to be dumbed down to the point that they no longer perform well on Oracle (or Postgres), because of mysql's crummy optimizer and lack of support for advanced join strategies. Eee, the plan is to *not* touch original code (unles

Re: [Spacewalk-devel] MySQL porting info

2009-04-28 Thread Jan Pazdziora
On Tue, Apr 28, 2009 at 10:10:01AM -0400, Tom Lane wrote: > > The usual experience AFAIR is that the queries have to be dumbed down to > the point that they no longer perform well on Oracle (or Postgres), > because of mysql's crummy optimizer and lack of support for advanced > join strategies. A

Re: [Spacewalk-devel] MySQL porting info

2009-04-28 Thread Tom Lane
=?ISO-8859-2?Q?Miroslav_Such=FD?= writes: > And IMO this approach has never been taken. But if you can point me to > somebody who tried to rewrite queries from oracle to mysql in runtime > and failed, I will be happy to read about it. The usual experience AFAIR is that the queries have to be du

Re: [Spacewalk-devel] MySQL porting info

2009-04-28 Thread Jan Pazdziora
On Mon, Apr 27, 2009 at 03:13:09PM +0200, Matej Hasul wrote: > Hello, I started working on migrating tables to mysql. > > Data types conversion looks like this: > > varchar2 -> varchar > number -> numeric > date -> timestamp > > Following problems emerged: > 1. Mysql doesn`t support user defined

Re: [Spacewalk-devel] MySQL porting info

2009-04-28 Thread Miroslav Suchý
Tom Lane wrote: =?ISO-8859-2?Q?Miroslav_Such=FD?= writes: Tom Lane wrote: Isn't this a complete waste of time? There is exactly 0 chance of migrating all those procedures to mysql. How do you know? Try it for awhile and see what you think. The incompatibilities and That is why Matej i

Re: [Spacewalk-devel] MySQL porting info

2009-04-27 Thread Tom Lane
=?ISO-8859-2?Q?Miroslav_Such=FD?= writes: > Tom Lane wrote: >> Isn't this a complete waste of time? There is exactly 0 chance of >> migrating all those procedures to mysql. > How do you know? Try it for awhile and see what you think. The incompatibilities and missing features you're running in

Re: [Spacewalk-devel] MySQL porting info

2009-04-27 Thread Miroslav Suchý
Tom Lane wrote: Matej Hasul writes: Hello, I started working on migrating tables to mysql. Isn't this a complete waste of time? There is exactly 0 chance of migrating all those procedures to mysql. How do you know? -- Miroslav Suchy Red Hat Satellite Engineering ___

Re: [Spacewalk-devel] MySQL porting info

2009-04-27 Thread Tom Lane
Matej Hasul writes: > Hello, I started working on migrating tables to mysql. Isn't this a complete waste of time? There is exactly 0 chance of migrating all those procedures to mysql. regards, tom lane ___ Spacewalk-devel mail

Re: [Spacewalk-devel] MySQL porting info

2009-04-27 Thread Miroslav Suchý
Matej Hasul wrote: Hello, I started working on migrating tables to mysql. Data types conversion looks like this: varchar2 -> varchar number -> numeric date -> timestamp For the records. Matej is trying to rewrite queries in run time to be MySQL compatible... Following problems emerged: 1

[Spacewalk-devel] MySQL porting info

2009-04-27 Thread Matej Hasul
Hello, I started working on migrating tables to mysql. Data types conversion looks like this: varchar2 -> varchar number -> numeric date -> timestamp Following problems emerged: 1. Mysql doesn`t support user defined data type. So I have no idea what to do with evr_t. 2. Mysql doesn`t support ne