Re: [GENERAL] Shell script to extract a table from a plain text dump
Argh! That's some sed coolness :) Chris Martijn van Oosterhout wrote: On Fri, Oct 07, 2005 at 04:46:12PM +0800, Christopher Kings-Lynne wrote: If you have huge plain text dumps, and just want to restore one table it's usually painful. Attached is a small shell script that can take a plain text dump and extract a single table's COPY data commands from it. If people think it's interesting and should be developed, I can pop it on pgfoundry or something. Hmm, what I usually use is: bzcat $file | sed -ne "/^COPY \"$table\" /,/^\\\.\$/p" However, error checking and wrapping it into a script is a good idea. If it got given a couple of switches to control the output, maybe we can have a pg_restore for text dumps :) Have a nice day, ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Oracle buys Innobase
Bruce Momjian schrieb: > Ultimately, MySQL should drop InnoDB. http://forums.mysql.com/read.php?3,48400,48400#msg-48400 InnoDB is GPL. But, i'm also confused. My guess: a fork in the future. Regards, Andreas -- Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect. (Linus Torvalds) Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889° ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] What Front-End you suggest ?
if you write a (warning incoming buzz-word) web-based front-end, it wouldn't have to be operating system specific, so why not use PGP for a middle layer and use XML (define an XML schema first) to pass information to a DHTML (javascript, XHTML, CSS) front-end. I have implemented this design with alot of sucess several times. On 10/7/05, Michael Schmidt <[EMAIL PROTECTED]> wrote: > > Mr. Armbrust, > Hopefully, this isn't off topic. Just wondering why SWT instead of swing? > > Michael Schmidt ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[GENERAL] triggers/constraints?
hello, consider a sample table: create table item (id serial, parent_id int, path varchar(256)); "id" is a unique identifier of each row, "parent_id" is an id of another row in the same table or null what is the right way in postgresql to ensure that the "path" field of a given row is a prefix of the "path" field of the row referenced by the "parent_id" field? check constraints? triggers? please advice, i am new. thanks in advance konstantin ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] PostgreSQL Gotchas
I use PostgeSQL less than year. Before I worked with MS SQL Server 2000, MySQL 3&4, Oracle8i and Interbase. Also, I studied standards SQL:1999 and SQL:2003. So, after switching to PostgreSQL I've encountered with several things that seem strange to me. Of course, several of them are simply not implemented yet and are in the list of unsopported features: http://www.postgresql.org/docs/8.0/interactive/unsupported-features-sql-standard.html. But some seem to be 'old diseases'. Here is my list of the issues: http://chernowiki.ru/Dev/PostgreSQLComparedWithSQL2003AndOracleSQLServerDB2Etc Perhaps I'm wrong with some issues - any comments are welcome. On 08/10/05, Jim C. Nasby <[EMAIL PROTECTED]> wrote: > On Fri, Oct 07, 2005 at 08:44:34AM +0100, Richard Huxton wrote: > > CSN wrote: > > >Yep, I think the SQL spec says fold to uppercase. I'm > > >not sure why PostgreSQL folds to lowercase instead, > > >but if folding has to occur, I prefer lowercase. > > > > I think preference was why lowercase was chosen many moons ago. It's > > stayed that way because otherwise existing users would be storming the > > -hackers list with pitchforks and flaming torches. > > If any change was made I'm sure it would be to allow the user to decide > which way case was folded. But IMHO, anyone messing around with object > names that won't fold is asking for trouble anyway. > -- > Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] > Pervasive Software http://pervasive.comwork: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > > ---(end of broadcast)--- > TIP 9: In versions below 8.0, the planner will ignore your desire to >choose an index scan if your joining column's datatypes do not >match > -- Best regards, Nikolay ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] triggers/constraints?
I believe you have a design problem. It seems to me that you need two tables; one with (id, path) and the other with (parent_id, path). Then you can use an UPDATE trigger on item which checks for a change in path. If it has changed, then you can update all those records in table "item2" where item2.parent_id matches item.id with the new prefix. You generally do not want to update other records in the same table with a trigger. This will send you into a loop unless you take special measures. HTH On Friday 07 October 2005 04:26 pm, ako... saith: > hello, > > consider a sample table: > > create table item (id serial, parent_id int, path varchar(256)); > > "id" is a unique identifier of each row, > "parent_id" is an id of another row in the same table or null > > what is the right way in postgresql to ensure that the "path" field of > a given row is a prefix of the "path" field of the row referenced by > the "parent_id" field? check constraints? triggers? > > please advice, i am new. > > thanks in advance > konstantin > > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] PostgreSQL Gotchas
On Sat, Oct 08, 2005 at 03:32:00PM +0400, Nikolay Samokhvalov wrote: > http://chernowiki.ru/Dev/PostgreSQLComparedWithSQL2003AndOracleSQLServerDB2Etc > > Perhaps I'm wrong with some issues - any comments are welcome. The only thing I can comment on is updatable views. You can make updatable views using RULEs. The only thing is that they're not *automatically* updateable. In theory, if someone came up will a program that from given produced the appropriate INSERT, UPDATE and DELETE rules, it might be incorporated. Currently you just have to do it manually... Case-insensetive text comparisons can be acheived using the citext module on gborg. http://gborg.postgresql.org/project/citext/projdisplay.php Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. pgpXtKEw89gLd.pgp Description: PGP signature
Re: [GENERAL] PostgreSQL Gotchas
On 08/10/05, Martijn van Oosterhout wrote: > On Sat, Oct 08, 2005 at 03:32:00PM +0400, Nikolay Samokhvalov wrote: > > http://chernowiki.ru/Dev/PostgreSQLComparedWithSQL2003AndOracleSQLServerDB2Etc > > > > Perhaps I'm wrong with some issues - any comments are welcome. > > The only thing I can comment on is updatable views. You can make > updatable views using RULEs. The only thing is that they're not > *automatically* updateable. OK, I'll make this correction. But for me, updatable views are views for which DBMS supports insert/update/delete operations as for tables. Ideally, people shouldn't distinguish table and view - that's what theory stands for (see Date's thoutghs about it: http://www.dbmsmag.com/int9410.html, he also has a cycle of articles on this theme: http://www.dbdebunk.citymax.com/page/page/622302.htm). PostgreSQL doesn't support updates even for simple views such as select-with-restriction. What it does support - not updatable views, but some kind of INSTEAD OFF triggers (another form of). > > In theory, if someone came up will a program that from given definition> produced the appropriate INSERT, UPDATE and DELETE rules, > it might be incorporated. Currently you just have to do it manually... There is a good theory (Date), but it cannot be implemented for any practical DBMS. The cause lies in differences between theory and practice. And the major difference is possibility to define tables w/o PK (in other words, possible duplicate rows). Nevertheless, all major commercial RDMSs support some subset of views that can be updated.. SQL:2003 defines a quite large subset, but the definition is pretty mazy... > > Case-insensetive text comparisons can be acheived using the citext > module on gborg. > > http://gborg.postgresql.org/project/citext/projdisplay.php Thanks for the link, I'll try it. However, I suppose that such basic feature as support collations should be implemented in core. > > Have a nice day, > -- > Martijn van Oosterhout http://svana.org/kleptog/ > > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > > tool for doing 5% of the work and then sitting around waiting for someone > > else to do the other 95% so you can sue them. > > > -- Best regards, Nikolay ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] PostgreSQL 8.1 vs. MySQL 5.0?
On 10/6/2005 4:37 AM, Tzvetan Tzankov wrote: They have collation and multiple characterset per table and etc. which actually is from 4.1 (not new in 5.0), and postgresql have only one collation per database cluster :-( Otherwise I think their features are all there, but cannot be used togather most of them (you can have foreign key, but not using fulltext ...) AFAIK MySQL's fulltext indexing is only supported on MyIsam tables, so if you want to use it, you lose ACID, hot backup and a couple other nice things entirely for that part of your data. Many MySQL users still believe that the pluggable storage engine design is an advantage ... I think one storage engine that supports the full feature set is better. Jan CSN wrote: Just so I know (and am armed ;) ), are there any new comparable features in MySQL 5.0 that aren't in PostgreSQL up to the forthcoming 8.1? AFAIK, PG just lacks updatable views (which are on the TODO). MySQL 5.0 new features http://dev.mysql.com/doc/mysql/en/mysql-5-0-nutshell.html Thanks, CSN __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 6: 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. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] SELECT FOR SHARE and FOR UPDATE
[Please copy the mailing list on replies so others can participate in and learn from the discussion.] On Sat, Oct 08, 2005 at 11:16:08AM +0400, Ilja Golshtein wrote: > I started to believe SELECT ... FOR SHARE is the remedy for my > problems. Unfortunately it is not till I cannot combine share and > exclusive locks for different tables in one query. > > I wonder if this limitation is fundamental or such a mixing of > lock modes could be allowed in future releases? I badly need this > feature. The documentation says "It is currently not allowed," which suggests that perhaps it could be allowed in a future version. Don't expect to see it in 8.1, however, since that version is long past feature freeze. I don't recall how much, if any, discussion there was on this; search the pgsql-hackers archives to find out. Could you tell us more about what you're doing? Maybe there's another way to achieve it. -- Michael Fuhr ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Oracle buys Innobase
Title: RE: [GENERAL] Oracle buys Innobase (This is via Exchange Web client, I apologize in advance for any htmlitudeiness of this message) What it comes down to is this. MySQL is dual licensed. You can use the GPL version, or the commercial version. In order to sell the commercially licensed version, MySQL must have the rights to all the code in their base. So, in order for MySQL to sell a commercail version of MySQL with innodb support, they have to pay innobase a bit to include it, or rip it out. So, now Oracle can just raise the price high enough that either the commercial version of MySQL has to go up to cover the price, or they are forced to remove it. If MySQL makes the choice to remove it from the commercial version, they will likely take it out of the GPL version as well, since they likely don't want the commercially licensed version to be the red headed step child of the GPL version, since their business plan relies on convincing people they need the commercial license as much as possible. -Original Message- From: [EMAIL PROTECTED] on behalf of Andreas Kretschmer Sent: Sat 10/8/2005 3:34 AM To: pgsql-general@postgresql.org Subject: Re: [GENERAL] Oracle buys Innobase Bruce Momjian schrieb: > Ultimately, MySQL should drop InnoDB. http://forums.mysql.com/read.php?3,48400,48400#msg-48400 InnoDB is GPL. But, i'm also confused. My guess: a fork in the future. Regards, Andreas -- Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect. (Linus Torvalds) Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889° ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Oracle buys Innobase
On 10/8/2005 4:34 AM, Andreas Kretschmer wrote: Bruce Momjian schrieb: Ultimately, MySQL should drop InnoDB. http://forums.mysql.com/read.php?3,48400,48400#msg-48400 InnoDB is GPL. But, i'm also confused. My guess: a fork in the future. This whole GPL forking thing is still the same as it was before. One can only take the last version, released under GPL, and build a GPL-only project based on it. Oracle bought the copyright of InnoDB with the company. So if anything goes wrong during their upcoming relicensing talk, MySQL can of course fork off a GPL version of InnoDB, but that fork cannot be included in their commercial version of MySQL. What value would that fork have for them then? Using a pure GPL fork of InnoDB is in conflict with their own licensing scheme and I don't think MySQL is in the position to say bye to dual licensing. To have a really good position when talking to Oracle, MySQL will need to brush up on the BDB support, and that pretty quick. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Oracle buys Innobase
Jan Wieck wrote: > On 10/8/2005 4:34 AM, Andreas Kretschmer wrote: > > > Bruce Momjian schrieb: > >> Ultimately, MySQL should drop InnoDB. > > > > http://forums.mysql.com/read.php?3,48400,48400#msg-48400 > > > > InnoDB is GPL. But, i'm also confused. > > > > My guess: a fork in the future. > > This whole GPL forking thing is still the same as it was before. One can > only take the last version, released under GPL, and build a GPL-only > project based on it. > > Oracle bought the copyright of InnoDB with the company. So if anything > goes wrong during their upcoming relicensing talk, MySQL can of course > fork off a GPL version of InnoDB, but that fork cannot be included in > their commercial version of MySQL. What value would that fork have for > them then? Using a pure GPL fork of InnoDB is in conflict with their own > licensing scheme and I don't think MySQL is in the position to say bye > to dual licensing. > > To have a really good position when talking to Oracle, MySQL will need > to brush up on the BDB support, and that pretty quick. What about the patents InnoDB might hold? It would be easier to enforce a patent based on the fact that they are using code actually developed by the patent holder. -- 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Oracle buys Innobase
On 10/8/2005 12:13 PM, Bruce Momjian wrote: Jan Wieck wrote: To have a really good position when talking to Oracle, MySQL will need to brush up on the BDB support, and that pretty quick. What about the patents InnoDB might hold? It would be easier to enforce a patent based on the fact that they are using code actually developed by the patent holder. That too. What strikes me a little odd is how brief the responses from the MySQL side are. Marten Mickos welcomes them, does some 2 sentence handwaving about licensing and the glorious freedom of open source, and then the rest of the statement is the usual blah blah about MySQL that you find in every other press release. It almost seems as if MySQL wasn't exactly prepared for this deal to come through - or worse, that they are surprised about it. Although I can't believe they wouldn't have known about it in advance. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] PostgreSQL Gotchas
On Sat, Oct 08, 2005 at 06:05:29PM +0400, Nikolay Samokhvalov wrote: > On 08/10/05, Martijn van Oosterhout wrote: > > The only thing I can comment on is updatable views. You can make > > updatable views using RULEs. The only thing is that they're not > > *automatically* updateable. > > OK, I'll make this correction. But for me, updatable views are views > for which DBMS supports insert/update/delete operations as for > tables. Ideally, people shouldn't distinguish table and view - that's > what theory stands for (see Date's thoutghs about it: > http://www.dbmsmag.com/int9410.html, he also has a cycle of articles > on this theme: http://www.dbdebunk.citymax.com/page/page/622302.htm). > PostgreSQL doesn't support updates even for simple views such as > select-with-restriction. What it does support - not updatable views, > but some kind of INSTEAD OFF triggers (another form of). You've got me confused. What are INSTEAD OF triggers? PostgreSQL does support views that look exactly like tables. You can decide on INSERT what to do whith fields not in the view, which columns you allow UPDATE and what the semantics should be for DELETE if the view is a join on multiple tables. All PostgreSQL doesn't do is create these rules for you. For an example see here, all the way at the bottom. RULEs are not TRIGGERs: http://www.varlena.com/varlena/GeneralBits/82.php > PK (in other words, possible duplicate rows). Nevertheless, all major > commercial RDMSs support some subset of views that can be updated.. > SQL:2003 defines a quite large subset, but the definition is pretty > mazy... PostgreSQL allows any view to be updatable, no matter how complex it is. You just have to create the rules yourself. There have been attempts to automate the process, they just havn't been clean enough to pass muster. And people who really want updateable views can make them already. Hope this clarifies things for you, -- Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. pgpfrCRF3LJIT.pgp Description: PGP signature
Re: [GENERAL] PostgreSQL 8.1 vs. MySQL 5.0?
> On 10/6/2005 4:37 AM, Tzvetan Tzankov wrote: > > > They have collation and multiple characterset per table and etc. which actually is from 4.1 (not new in 5.0), and postgresql have only one collation per database cluster :-( > > Otherwise I think their features are all there, but cannot be used togather most of them (you can have foreign key, but not using fulltext ...) > > > AFAIK MySQL's fulltext indexing is only supported on MyIsam tables, so if you want to use it, you lose ACID, hot backup and a couple other nice things entirely for that part of your data. Many MySQL users still believe that the pluggable storage engine design is an advantage ... I think one storage engine that supports the full feature set is better. > > Jan I agree - MySQL really has a confusing array of different database engines: # MyISAM # MERGE # ISAM # HEAP # InnoDB # BDB or BerkeleyDB Tables # Example # Archive # Federated # CSV # Blackhole # NDB Cluster http://dev.mysql.com/doc/mysql/en/storage-engines.html CSN __ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Oracle buys Innobase
Hi That is terrific news being a former employee of MySQL - Oracle buys Innobase. I was never a fan of MySQL, personally but when Marten Mikos and the rest of the business wonks joined the Company I knew then it was time to get out. I met the author of Innobase once at the first MySQL employees meeting. I was asked what for an opinion on Heikki Tuuri. I came straight to point and told Monty and David (Axmark) that Heikki Tuuri can not be trusted. It seems I was right. Mr Tuuri has no interest in supporting the OS commumity. His only interest is in making money. My gut feeling now is that eventually Oracle will buy off Innobase lock stock and barell Then Innonbase will get consigned to File 13. I now see MySQL heading for a long slow death; it couldn't happen to a nicer group of people :) Thank God for PostreSQL At 18:42 08/10/2005, Jan Wieck wrote: On 10/8/2005 12:13 PM, Bruce Momjian wrote: Jan Wieck wrote: To have a really good position when talking to Oracle, MySQL will need to brush up on the BDB support, and that pretty quick. What about the patents InnoDB might hold? It would be easier to enforce a patent based on the fact that they are using code actually developed by the patent holder. That too. What strikes me a little odd is how brief the responses from the MySQL side are. Marten Mickos welcomes them, does some 2 sentence handwaving about licensing and the glorious freedom of open source, and then the rest of the statement is the usual blah blah about MySQL that you find in every other press release. It almost seems as if MySQL wasn't exactly prepared for this deal to come through - or worse, that they are surprised about it. Although I can't believe they wouldn't have known about it in advance. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings --- Regards John Dean, co-author of Rekall, the only alternative to MS Access ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Oracle buys Innobase
Jan Wieck wrote: To have a really good position when talking to Oracle, MySQL will need to brush up on the BDB support, and that pretty quick. Maybe Oracle will buy Sleepycat too, and foreclose that option ;-) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Oracle buys Innobase
On Sat, 8 Oct 2005, Jan Wieck wrote: On 10/8/2005 12:13 PM, Bruce Momjian wrote: Jan Wieck wrote: To have a really good position when talking to Oracle, MySQL will need to brush up on the BDB support, and that pretty quick. What about the patents InnoDB might hold? It would be easier to enforce a patent based on the fact that they are using code actually developed by the patent holder. That too. What strikes me a little odd is how brief the responses from the MySQL side are. Marten Mickos welcomes them, does some 2 sentence handwaving about licensing and the glorious freedom of open source, and then the rest of the statement is the usual blah blah about MySQL that you find in every other press release. It almost seems as if MySQL wasn't exactly prepared for this deal to come through - or worse, that they are surprised about it. Although I can't believe they wouldn't have known about it in advance. Or, they knew about it and have some sort of contigency plan already in place for when the license does expire ... ? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [GENERAL] Oracle buys Innobase
Bruce, Aly, > > Hopefully that should make PostgreSQL shine even more. Maybe we > > may also see some @sun.com contributers, okay that maybe wishful > > thinking. > > I have seen @sun.com posters already, so it has started. Actually, the Sun folks have been contributing indirectly for a while, and are working on getting Solaris binary packaging organized. They're just not big on joining mailing lists, something we need to educate them on. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] PostgreSQL 8.1 vs. MySQL 5.0?
On Oct 8, 2005, at 2:04 PM, CSN wrote: AFAIK MySQL's fulltext indexing is only supported on MyIsam tables, so if you want to use it, you lose ACID, For me, the fact that to use a feature means one needs to give up ACIDity ends any debate on which DB to choose, and I'm not even a power user. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Oracle buys Innobase
On Sat, Oct 08, 2005 at 10:31:30AM -0500, Scott Marlowe wrote: > What it comes down to is this. MySQL is dual licensed. You can use > the GPL version, or the commercial version. In order to sell the > commercially licensed version, MySQL must have the rights to all the > code in their base. So, in order for MySQL to sell a commercail > version of MySQL with innodb support, they have to pay innobase a > bit to include it, or rip it out. I don't understand. If both MySQL and Innodb are GPL licensed, commercial or not should make no difference, and they can add all the GPL changes they want o the last Innodb GPL release. What am I missing? -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & rocket surgeon / [EMAIL PROTECTED] GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Oracle buys Innobase
El Sáb 08 Oct 2005 18:11, [EMAIL PROTECTED] escribió: > On Sat, Oct 08, 2005 at 10:31:30AM -0500, Scott Marlowe wrote: > > > What it comes down to is this. MySQL is dual licensed. You can use > > the GPL version, or the commercial version. In order to sell the > > commercially licensed version, MySQL must have the rights to all the > > code in their base. So, in order for MySQL to sell a commercail > > version of MySQL with innodb support, they have to pay innobase a > > bit to include it, or rip it out. > > I don't understand. If both MySQL and Innodb are GPL licensed, > commercial or not should make no difference, and they can add all the > GPL changes they want o the last Innodb GPL release. > > What am I missing? They can't enforce a commercial licence over a GPL aplication. -- select 'mmarques' || '@' || 'unl.edu.ar' AS email; - Martín Marqués | Programador, DBA Centro de Telemática| Administrador Universidad Nacional del Litoral - ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Dump all except some tables?
On Fri, Oct 07, 2005 at 08:21:31PM -0500, Jim C. Nasby wrote: > On Fri, Oct 07, 2005 at 02:07:47AM -0700, David Fetter wrote: > > On Fri, Oct 07, 2005 at 11:47:26AM +0300, WireSpot wrote: > > > But... will the resulting dump be consistent as far as foreign > > > keys are concerned? Or will the current -t warning still apply > > > (YMMV as to the consistency of the resulting dump)? > > > > I think the latter is better. This is solidly in the realm of > > prying off cover plates, and the warning is already there :) > > I think it would be good to include an option that only does > checking and doesn't actually try to dump anything. That would make > it easier to ensure your config file is correct. Could you flesh this out a bit? What would this option produce in the (imho most common) case where dependencies weren't all taken care of? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Dump all except some tables?
On Sat, Oct 08, 2005 at 02:22:23PM -0700, David Fetter wrote: > On Fri, Oct 07, 2005 at 08:21:31PM -0500, Jim C. Nasby wrote: > > On Fri, Oct 07, 2005 at 02:07:47AM -0700, David Fetter wrote: > > > On Fri, Oct 07, 2005 at 11:47:26AM +0300, WireSpot wrote: > > > > But... will the resulting dump be consistent as far as foreign > > > > keys are concerned? Or will the current -t warning still apply > > > > (YMMV as to the consistency of the resulting dump)? > > > > > > I think the latter is better. This is solidly in the realm of > > > prying off cover plates, and the warning is already there :) > > > > I think it would be good to include an option that only does > > checking and doesn't actually try to dump anything. That would make > > it easier to ensure your config file is correct. > > Could you flesh this out a bit? What would this option produce in the > (imho most common) case where dependencies weren't all taken care of? For one thing, it would produce a list of missing dependancies (or any other errors that could be detected without doing the actual dump, for that matter). I think that when trying to setup a non-trival dump scenario, it would be great to actually produce output stating exactly what dump would have done had it run for real. One way to think of it would be running pg_dump -v and piping stdout to /dev/null. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Oracle buys Innobase
On Oct 8, 2005, at 5:11 PM, [EMAIL PROTECTED] wrote: I don't understand. If both MySQL and Innodb are GPL licensed, commercial or not should make no difference, and they can add all the GPL changes they want o the last Innodb GPL release. MySQL owns their code so they can release it with whatever license they want. Since they don't own the Innodb code they can't include it in a commercially licensed product. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] PostgreSQL Gotchas
Neil Conway wrote: > "SELECT column alias, ...": this is a known issue. AFAIK it is not > easy to solve. It's easy to solve. There's even a patch linked from the page. I seem to remember that some (versions of some?) other SQL implementation did not *allow* the AS there, complicating matters for people moving to PostgreSQL. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Oracle buys Innobase
On Sat, Oct 08, 2005 at 02:11:54PM -0700, [EMAIL PROTECTED] wrote: > On Sat, Oct 08, 2005 at 10:31:30AM -0500, Scott Marlowe wrote: > > > What it comes down to is this. MySQL is dual licensed. You can use > > the GPL version, or the commercial version. In order to sell the > > commercially licensed version, MySQL must have the rights to all the > > code in their base. So, in order for MySQL to sell a commercail > > version of MySQL with innodb support, they have to pay innobase a > > bit to include it, or rip it out. > > I don't understand. If both MySQL and Innodb are GPL licensed, > commercial or not should make no difference, and they can add all the > GPL changes they want o the last Innodb GPL release. > > What am I missing? MySQL isn't GPL, it's a modified GPL. But the real issue is that they can't use the GPL licensed InnoDB in their commercial product. They have to obtain a commercial license for that. And I suspect Oracle's going to want more than they can afford for that license. Though AFAIK there wouldn't be anything illegal about someone with a commercial license of MySQL using the GPL'd version of InnoDB... but of course if they did that they'd have GPL'd software again, so no reason to pay for the commercial license of MySQL. This is the first time I can think of where software being GPL'd might actually hurt the open-source community. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Oracle buys Innobase
[EMAIL PROTECTED] writes: > I don't understand. If both MySQL and Innodb are GPL licensed, > commercial or not should make no difference, and they can add all the > GPL changes they want o the last Innodb GPL release. > What am I missing? MySQL AB wants to make money by selling non-GPL versions of MySQL. They can certainly dual-license MySQL itself, because they own it outright, but they could not ship InnoDB as part of a non-GPL-license MySQL sale without InnoDB's (and now Oracle's) permission. So they've got a financial problem with this. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Oracle buys Innobase
On 10/8/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I don't understand. If both MySQL and Innodb are GPL licensed, > commercial or not should make no difference, and they can add all the > GPL changes they want o the last Innodb GPL release. They can only do the GPL stuff in the GPL-licensed MySQL; and they cannot incorporate someone else's GPL works in a proprietary (non-GPL) commercial release. This basically means that InnoDB table support must come out of the commercial MySQL. -- Mitch ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Oracle buys Innobase
On 10/8/05, Mitch Pirtle <[EMAIL PROTECTED]> wrote: > > This basically means that InnoDB table support must come out of the > commercial MySQL. For that matter, I'm not sure they can release MySQL under a commercial license while incorporating 3rd party GPL works, without the express permission of the copyright holders for those included works. Whatever deal they used to have just got changed, that's for sure. -- Mitch ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Oracle buys Innobase
[EMAIL PROTECTED] writes: > On Sat, Oct 08, 2005 at 10:31:30AM -0500, Scott Marlowe wrote: > >> What it comes down to is this. MySQL is dual licensed. You can use >> the GPL version, or the commercial version. In order to sell the >> commercially licensed version, MySQL must have the rights to all the >> code in their base. So, in order for MySQL to sell a commercail >> version of MySQL with innodb support, they have to pay innobase a >> bit to include it, or rip it out. > > I don't understand. If both MySQL and Innodb are GPL licensed, > commercial or not should make no difference, and they can add all > the GPL changes they want o the last Innodb GPL release. Yes, that is correct, MySQL can still distribute a GPLed version of MySQL that includes InnoDB no matter what Oracle might do. However, MySQL AB's current business strategy relies heavily on being able to sell MySQL under a commercial license. If Oracle changes the deal that MySQL AB has with InnoBase then it will be impossible for MySQL AB to sell a version of MySQL with support for InnoDB tables under a commercial license. All of MySQL's fancy new features revolve around the far more capable InnoDB tables. Without that table type MySQL reverts right back to the toy it was at version 3.2. MyISAM tables lack ACID transactions, row level locking, hot backup ability, and basically everything else you would want out of a database. Oracle now has MySQL AB over a barrel. I imagine that when it comes time to renegotiate the InnoBase license next year that the balance of power in that relationship will shift dramatically. > What am I missing? What you are missing is that MySQL AB the company and MySQL the database are two different things. MySQL the database will still be distributable under the GPL, but even MySQL AB isn't going to be able to distribute MySQL with the InnoDB table type under anything but the GPL if Oracle yanks MySQL AB's license. Of course, it's entirely possible that Oracle isn't planning to torpedo MySQL and that the InnoBase/MySQL AB relationship will remain unchanged, but this news has got to make MySQL AB's commercial customers nervous. Jason ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Oracle buys Innobase
On Sat, Oct 08, 2005 at 02:11:54PM -0700, [EMAIL PROTECTED] wrote: > > What am I missing? [ many answers ] Ahhh ... I did not realize they were selling a commercial version with a dual license. I had thought they were selling support contracts. I confess I find this weird too. I can't see why someone wouild want to distribute their own private label version of MySQL, unless they were making significant changes, and then I can't see why anyone would want to buy such a version. But I have met many people, not just corporate types, who think $0 = worthless, and $$ not as good as $$, even for the exact same piece of gear. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & rocket surgeon / [EMAIL PROTECTED] GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Oracle buys Innobase
[EMAIL PROTECTED] writes: > On Sat, Oct 08, 2005 at 10:31:30AM -0500, Scott Marlowe wrote: > >> What it comes down to is this. MySQL is dual licensed. You can use >> the GPL version, or the commercial version. In order to sell the >> commercially licensed version, MySQL must have the rights to all the >> code in their base. So, in order for MySQL to sell a commercail >> version of MySQL with innodb support, they have to pay innobase a >> bit to include it, or rip it out. > > I don't understand. If both MySQL and Innodb are GPL licensed, > commercial or not should make no difference, and they can add all the > GPL changes they want o the last Innodb GPL release. > > What am I missing? If they do not hold a fairly unrestricted license to *resell* InnoDB, then MySQL AB would be unable to sell "traditional proprietary commercial licenses" to the combination of MySQL and InnoDB, which is the way that they actually _make money_. Based on the comments in Oracle's press release, it appears that MySQL AB *does* have some form of contract with InnoDB Oy Inc to resell InnoDB, but that contract expires some time next year. If the contract is not renewed, then MySQL AB would only be permitted to link MySQL (tm) to InnoDB under the conditions of the GPL, which would mean that MySQL AB could only distribute a MySQL(tm)/InnoDB(tm) combination under the conditions of the GPL. This would essentially *destroy* their revenue model, which is predicated on the notion of selling people a "traditional proprietary license" to MySQL+InnoDB on the basis that they should be fearful of GPL-licensed software as it always forces you to release your code "for free." (There's some truth to this, but possibly not as much as MySQL AB would have you believe.) -- let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];; http://www.ntlug.org/~cbbrowne/oses.html Black holes are where God divided by zero. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Dump all except some tables?
[EMAIL PROTECTED] (David Fetter) writes: > On Fri, Oct 07, 2005 at 08:21:31PM -0500, Jim C. Nasby wrote: >> On Fri, Oct 07, 2005 at 02:07:47AM -0700, David Fetter wrote: >> > On Fri, Oct 07, 2005 at 11:47:26AM +0300, WireSpot wrote: >> > > But... will the resulting dump be consistent as far as foreign >> > > keys are concerned? Or will the current -t warning still apply >> > > (YMMV as to the consistency of the resulting dump)? >> > >> > I think the latter is better. This is solidly in the realm of >> > prying off cover plates, and the warning is already there :) >> >> I think it would be good to include an option that only does >> checking and doesn't actually try to dump anything. That would make >> it easier to ensure your config file is correct. > > Could you flesh this out a bit? What would this option produce in the > (imho most common) case where dependencies weren't all taken care of? I'd think that throwing in the "-s" option would allow a meaningful dry run... -- let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;; http://www.ntlug.org/~cbbrowne/languages.html Frisbeetarianism: The belief that when you die, your soul goes up on the roof and gets stuck... ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Oracle buys Innobase
On Oct 8, 2005, at 6:40 PM, Mitch Pirtle wrote: On 10/8/05, Mitch Pirtle <[EMAIL PROTECTED]> wrote: This basically means that InnoDB table support must come out of the commercial MySQL. For that matter, I'm not sure they can release MySQL under a commercial license while incorporating 3rd party GPL works, without the express permission of the copyright holders for those included works. Whatever deal they used to have just got changed, that's for sure. -- Mitch All of which seems to beg the question: why did not MySQL buy Innobase themselves? As far as I've read, the terms of the transaction were not disclosed. I guess it's possible that MySQL didn't have the financial reach to pull off the deal. -- Thomas F. O'Connell Co-Founder, Information Architect Sitening, LLC Strategic Open Source: Open Your i™ http://www.sitening.com/ 110 30th Avenue North, Suite 6 Nashville, TN 37203-6320 615-469-5150 615-469-5151 (fax) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Oracle buys Innobase
> All of which seems to beg the question: why did not MySQL buy > Innobase themselves? As far as I've read, the terms of the > transaction were not disclosed. I guess it's possible that MySQL > didn't have the financial reach to pull off the deal. Maybe they didn't think it was necessary. In any event, they're far from the first (or last) company to underestmate the aggressive business tactics of Oracle, which isn't doing this out of the goodness of their hearts. My guess is that the people at Oracle looked at the number of ISPs who offer their customers MySQL database support and saw a market to tap. Oracle's tried to tap the 'small database server' market before, badly. If the folks at MySQL AB are smart, they may be considering selling out to Oracle too, before they get left out in the cold. Are there any lessons to be learned from this with regards to PostgreSQL? -- Mike Nolan ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Oracle buys Innobase
On Sat, 8 Oct 2005, Mike Nolan wrote: All of which seems to beg the question: why did not MySQL buy Innobase themselves? As far as I've read, the terms of the transaction were not disclosed. I guess it's possible that MySQL didn't have the financial reach to pull off the deal. Maybe they didn't think it was necessary. In any event, they're far from the first (or last) company to underestmate the aggressive business tactics of Oracle, which isn't doing this out of the goodness of their hearts. My guess is that the people at Oracle looked at the number of ISPs who offer their customers MySQL database support and saw a market to tap. Oracle's tried to tap the 'small database server' market before, badly. If the folks at MySQL AB are smart, they may be considering selling out to Oracle too, before they get left out in the cold. Are there any lessons to be learned from this with regards to PostgreSQL? IMHO, not really ... nobody *owes* the PostgreSQL code base, and we aren't reliant on any third parties for key parts of the server, so Oracle would essentially have to go after the commercial vendors themselves, and even going after them wouldn't buy them *that* much, I wouldn't think ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Oracle buys Innobase
[EMAIL PROTECTED] writes: > On Sat, Oct 08, 2005 at 02:11:54PM -0700, [EMAIL PROTECTED] wrote: >> >> What am I missing? > > [ many answers ] > > Ahhh ... I did not realize they were selling a commercial version with > a dual license. I had thought they were selling support contracts. > > I confess I find this weird too. I can't see why someone wouild > want to distribute their own private label version of MySQL, unless > they were making significant changes, and then I can't see why > anyone would want to buy such a version. But I have met many > people, not just corporate types, who think $0 = worthless, and $$ > not as good as $$, even for the exact same piece of gear. That's part of the reason that MySQL AB went around to all of the MySQL database adaptor guys and hired them and changed the license on them to the GPL. There were lots of people that wanted to include a database with their software and LGPLed drivers let them do that even if the database itself was under the GPL. Now with GPLed drivers for MySQL if you distribute your application you either need a commercial license of MySQL or you need to GPL your application. MySQL made a pretty penny convincing application writers that they needed a commercial license of MySQL if their application wasn't distributed under the GPL. It wasn't about support contracts per se, but rather about being able to include an inexpensive database with a commercial application. In some ways that actually shouldn't be a problem since the drivers are the part get gets "linked" with the commercial application, and they are still owned by MySQL AB. However, it's going to look funny if MySQL AB has to offer MySQL itself under the GPL in order to include InnoDB tables and they simply sell the database drivers under a commercial license. Any way you look at it, there are interesting times ahead for MySQL AB. Personally I think that it is just Karma. After years of disinformation they are getting what they deserve. Jason ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] PostgreSQL Gotchas
On 10/8/05, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote: > I use PostgeSQL less than year. Before I worked with MS SQL Server > 2000, MySQL 3&4, Oracle8i and Interbase. Also, I studied standards > SQL:1999 and SQL:2003. So, after switching to PostgreSQL I've > encountered with several things that seem strange to me. Of course, > several of them are simply not implemented yet and are in the list of > unsopported features: > http://www.postgresql.org/docs/8.0/interactive/unsupported-features-sql-standard.html. > But some seem to be 'old diseases'. > > Here is my list of the issues: > http://chernowiki.ru/Dev/PostgreSQLComparedWithSQL2003AndOracleSQLServerDB2Etc > > Perhaps I'm wrong with some issues - any comments are welcome. > From the referenced page... "We can insert into column of type TIME the value such as '12:15' and then obtain '12:15:00' making select, but we couldn't do the same with dates." Huh? Minutes and seconds have a valid value of zero. Months and days don't. Date types need to contain a valid date, and time types need to contain a valid time. Anything else seems like, well, MySQL. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Oracle buys Innobase
On Saturday 08 October 2005 17:35, Chris Browne wrote: > [EMAIL PROTECTED] writes: > > On Sat, Oct 08, 2005 at 10:31:30AM -0500, Scott Marlowe wrote: > >> What it comes down to is this. MySQL is dual licensed. You can use > >> the GPL version, or the commercial version. In order to sell the > >> commercially licensed version, MySQL must have the rights to all the > >> code in their base. So, in order for MySQL to sell a commercail > >> version of MySQL with innodb support, they have to pay innobase a > >> bit to include it, or rip it out. > > > > I don't understand. If both MySQL and Innodb are GPL licensed, > > commercial or not should make no difference, and they can add all the > > GPL changes they want o the last Innodb GPL release. > > > > What am I missing? > > If they do not hold a fairly unrestricted license to *resell* InnoDB, > then MySQL AB would be unable to sell "traditional proprietary > commercial licenses" to the combination of MySQL and InnoDB, which is > the way that they actually _make money_. > > Based on the comments in Oracle's press release, it appears that MySQL > AB *does* have some form of contract with InnoDB Oy Inc to resell > InnoDB, but that contract expires some time next year. > > If the contract is not renewed, then MySQL AB would only be permitted > to link MySQL (tm) to InnoDB under the conditions of the GPL, which > would mean that MySQL AB could only distribute a MySQL(tm)/InnoDB(tm) > combination under the conditions of the GPL. > > This would essentially *destroy* their revenue model, which is > predicated on the notion of selling people a "traditional proprietary > license" to MySQL+InnoDB on the basis that they should be fearful of > GPL-licensed software as it always forces you to release your code > "for free." (There's some truth to this, but possibly not as much as > MySQL AB would have you believe.) Didn't MySQL AB acquire SAPdb (which was Adabas D before)? AFAIK (and you're welcome to correct me since I might very well be wrong) SAPdb supports transactions and foreign keys. If that's the case MySQL AB might be in a position to offer the bells and whistles without InnoDB support if they work out the deficiencies of SAPdb. -- UC -- Open Source Solutions 4U, LLC 2570 Fleetwood Drive Phone: +1 650 872 2425 San Bruno, CA 94066 Cell: +1 650 302 2405 United States Fax:+1 650 872 2417 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Oracle buys Innobase
On Oct 8, 2005, at 10:34 PM, Marc G. Fournier wrote: Are there any lessons to be learned from this with regards to PostgreSQL? Like Marc said, doesn't seem to be a worry to the Postgres community . . . Unless this is all really an Oracle ploy to grab the competition to the their real future fear . . . PostgreSQL X : ) Seriously though, whereas MySQL's ease of use was a draw to the burgeoning web designers-turned-PHP codies, a lot of heavy DB users considered and still consider Postgres the open-source alternative to Oracle. When I was new to DB newbie, I followed that crowd (like the OpenACS folks) from Oracle to Postgres. While this deal doesn't change the quality of MySQL at all yet, it could affect the evangelizing efforts of the community. It can't help, I wouldn't think, unless Oracle just smothers them out, which is possible, though not probable, since the two database's customers are so different and there is money to be made by keeping the DB alive. A community would always remain to take up the torch, but the Postgres community builds Postgres, while the MySQL community has a different dynamic entirely. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Oracle buys Innobase
[EMAIL PROTECTED] wrote: > I confess I find this weird too. I can't see why someone wouild want > to distribute their own private label version of MySQL, unless they > were making significant changes, and then I can't see why anyone > would want to buy such a version. The suits do this for peace of mind. They are very nervous about entrusting corporate data to open source databases with no support. Why else do you think companies are willing to pay Oracle $300,000 per CPU? At 2 am if something gets corrupted, they can call Oracle and attempt to get it fixed. -- Guy Rouillier ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Oracle buys Innobase
[EMAIL PROTECTED] ("Thomas F. O'Connell") writes:
> On Oct 8, 2005, at 6:40 PM, Mitch Pirtle wrote:
>
>> On 10/8/05, Mitch Pirtle <[EMAIL PROTECTED]> wrote:
>>
>>> This basically means that InnoDB table support must come out of the
>>> commercial MySQL.
>>
>> For that matter, I'm not sure they can release MySQL under a
>> commercial license while incorporating 3rd party GPL works, without
>> the express permission of the copyright holders for those included
>> works.
>>
>> Whatever deal they used to have just got changed, that's for sure.
>
> All of which seems to beg the question: why did not MySQL buy
> Innobase themselves? As far as I've read, the terms of the
> transaction were not disclosed. I guess it's possible that MySQL
> didn't have the financial reach to pull off the deal.
It is interesting that MySQL AB did not put some option into their
original deal with InnoDB that would make it easy for them to do a
buyout of the code in case "something naughty might happen."
If I were making my product dependent on [X], I'd want to be careful
to assure myself that I could continue to have access to [X];
according to what I see in the Oracle statement, it doesn't appear as
though there was anything more specific than a contract ending some
time next year.
Mind you, it is not public what goes away in 2006. It is possible
that MySQL AB has a more-or-less perpetual license to use InnoDB as it
stands today, in which case it would be entirely possible that they
would fork the code base, and maintain the "MySQL version of InnoDB"
themselves. Continuing access to the present version would represent
a reasonable "option" for MySQL AB...
In any case, there are doubtless a few lawyers in Europe that are
pretty busy this weekend :-).
--
output = ("cbbrowne" "@" "acm.org")
http://www.ntlug.org/~cbbrowne/linuxxian.html
I just removed the instructions in MC:COMMON;LINS > which specify that
it should be installed on AI. We'll certainly miss that machine, and
probably spend the rest of our lives fixing programs that mention it.
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Oracle buys Innobase
On Oct 8, 2005, at 11:25 PM, Uwe C. Schroeder wrote: Didn't MySQL AB acquire SAPdb (which was Adabas D before)? AFAIK (and you're welcome to correct me since I might very well be wrong) SAPdb supports transactions and foreign keys. If that's the case MySQL AB might be in a position to offer the bells and whistles without InnoDB support if they work out the deficiencies of SAPdb. Or maybe SQLite? I was looking for some other options and saw this page. It look like the author mistakenly calls PostgreSQL GPL'd. http://linas.org/linux/db.html ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[GENERAL] possible bug : pg_dump does not include ALTER DATABASE SET search_path
possible bug : pg_dump does not include ALTER DATABASE ... SET search_path TO ... pg_dumpall does include it. pg_dump only includes the runtime "SET search_path", but not the permanent ALTER DATABASE part is this intentional?
Re: [GENERAL] possible bug : pg_dump does not include ALTER DATABASE SET search_path
Miles Keaton <[EMAIL PROTECTED]> writes: > pg_dump does not include ALTER DATABASE ... SET search_path TO ... > pg_dumpall does include it. This is per design; it holds for all ALTER DATABASE properties not just search_path. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Oracle buys Innobase
[EMAIL PROTECTED] ("Uwe C. Schroeder") writes:
> Didn't MySQL AB acquire SAPdb (which was Adabas D before)? AFAIK
> (and you're welcome to correct me since I might very well be wrong)
> SAPdb supports transactions and foreign keys. If that's the case
> MySQL AB might be in a position to offer the bells and whistles
> without InnoDB support if they work out the deficiencies of SAPdb.
They did that indeed, or at least they acquired a license to SAP-DB.
(I think SAP AG retains license as well; this is akin to the way USL
sold SysV licenses to many vendors...)
The problems with Max-DB are twofold:
1. It isn't at all compatible with the "legacy" MySQL applications.
It is essentially a database system with a similar "flavour" to
Oracle version 7. That's not much similar to MySQL 3.x or 4.x.
2. The code base was pretty old, pretty creaky, and has a *really*
heavy learning curve.
It was pretty famous as being *really* difficult to build; throw
together such things as:
- It uses a custom set of build tools that were created for a
mainframe environment and sorta hacked into Python
- Naming conventions for files, variables, and functions combine
pseudo-German with an affinity for 8 character names that are
anything but mnemonic. (Think: "Germans developing on MVS.")
- I seem to recall there being a Pascal translator to transform
some of the code into C++...
Doing substantial revisions to it seems unlikely. Doing terribly
much more than trying to keep it able to compile on a few
platforms of interest seems unlikely.
When they announced at OSCON that MySQL 5.0 would have all of the
features essential to support SAP R/3, that fit the best theories
available as to why they took on "MaxDB", namely to figure out the
minimal set of additions needed to get MySQL to be able to host R/3.
If that be the case, then Oracle just took about the minimal action
necessary to take the wind out of their sails :-).
--
"cbbrowne","@","cbbrowne.com"
http://cbbrowne.com/info/linuxdistributions.html
Atheism is a non-prophet organization.
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [GENERAL] Oracle buys Innobase
Chris Browne <[EMAIL PROTECTED]> writes: > When they announced at OSCON that MySQL 5.0 would have all of the > features essential to support SAP R/3, that fit the best theories > available as to why they took on "MaxDB", namely to figure out the > minimal set of additions needed to get MySQL to be able to host R/3. [ Trying to drag this thread back to something Postgres-related ;-) ] Does anyone have a clear idea how far *we* are from being able to support SAP? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[GENERAL] brain-teaser with CONSTRAINT - any SQL experts?
I'm stuck on a brain-teaser with CONSTRAINT: Imagine a table like "lineitems" in a bookstore - where you don't need an ISBN to be unique because a book will be in buying history more than once. But you DO need to make sure that the ISBN number is ONLY matched to one book name - NOT to more than one book name. This is OK: isbnname 1234Red Roses 1234Red Roses This is OK: (two books can have the same name) isbnname 1234Red Roses Red Roses This is NOT OK: (an isbn must be tied to one book only!) isbnname 1234Red Roses 1234Green Glasses I know it's tempting to say, "just link a separate table for the book and don't store the book name" but let's just pretend that's not an option - because I'm not actually dealing with books : I just made up this simplified version of something at work, where we can't change the table : both isbn and name MUST be in the table, and what I'm trying to do is put a CONSTRAINT on the table definition to protect against user error, by making sure that any entered isbn is only tied to one book-name in that table. Thoughts? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Oracle buys Innobase
On Saturday 08 October 2005 21:07, Chris Browne wrote:
> [EMAIL PROTECTED] ("Uwe C. Schroeder") writes:
> > Didn't MySQL AB acquire SAPdb (which was Adabas D before)? AFAIK
> > (and you're welcome to correct me since I might very well be wrong)
> > SAPdb supports transactions and foreign keys. If that's the case
> > MySQL AB might be in a position to offer the bells and whistles
> > without InnoDB support if they work out the deficiencies of SAPdb.
>
> They did that indeed, or at least they acquired a license to SAP-DB.
> (I think SAP AG retains license as well; this is akin to the way USL
> sold SysV licenses to many vendors...)
>
> The problems with Max-DB are twofold:
>
> 1. It isn't at all compatible with the "legacy" MySQL applications.
>
> It is essentially a database system with a similar "flavour" to
> Oracle version 7. That's not much similar to MySQL 3.x or 4.x.
>
> 2. The code base was pretty old, pretty creaky, and has a *really*
> heavy learning curve.
>
> It was pretty famous as being *really* difficult to build; throw
> together such things as:
> - It uses a custom set of build tools that were created for a
> mainframe environment and sorta hacked into Python
> - Naming conventions for files, variables, and functions combine
> pseudo-German with an affinity for 8 character names that are
> anything but mnemonic. (Think: "Germans developing on MVS.")
> - I seem to recall there being a Pascal translator to transform
> some of the code into C++...
WOW - careful now. I'm german - but then, there's a reason why I immigrated to
the US :-)
>
> Doing substantial revisions to it seems unlikely. Doing terribly
> much more than trying to keep it able to compile on a few
> platforms of interest seems unlikely.
>
> When they announced at OSCON that MySQL 5.0 would have all of the
> features essential to support SAP R/3, that fit the best theories
> available as to why they took on "MaxDB", namely to figure out the
> minimal set of additions needed to get MySQL to be able to host R/3.
>
> If that be the case, then Oracle just took about the minimal action
> necessary to take the wind out of their sails :-).
SAPdb (aka Adabas D) is something I worked with quite a while ago. And you're
right, the naming schemes and restrictions, as well as severe
incompatibilities with the SQL standard where one of my major reasons to drop
that database in favor of Informix (at that time) and PostgreSQL later on.
It was kind of tough to generate explanatory table names with those kind of
limitations. Nonetheless back then (maybe around 1993) Adabas D was a quite
powerful and considerably cheap alternative to anything serious at the market
- and it was easy to sell to customers (back in germany) just because this
was THE database powering SAP R/3.
But you may be right - considering what the codebase of SAPdb must look like
it's probably unlikely MySQL AB can make any considerable improvements in the
time available.
UC
--
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax:+1 650 872 2417
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] brain-teaser with CONSTRAINT - any SQL experts?
how about using 2 tables with according unique/primary key constraints and a view to actually access the data (mixing the 2 tables into one) ? On Saturday 08 October 2005 22:36, Miles Keaton wrote: > I'm stuck on a brain-teaser with CONSTRAINT: > > Imagine a table like "lineitems" in a bookstore - where you don't need > an ISBN to be unique because a book will be in buying history more > than once. > > But you DO need to make sure that the ISBN number is ONLY matched to > one book name - NOT to more than one book name. > > This is OK: > isbnname > 1234Red Roses > 1234Red Roses > > This is OK: (two books can have the same name) > isbnname > 1234Red Roses > Red Roses > > This is NOT OK: (an isbn must be tied to one book only!) > isbnname > 1234Red Roses > 1234Green Glasses > > > I know it's tempting to say, "just link a separate table for the book > and don't store the book name" but let's just pretend that's not an > option - because I'm not actually dealing with books : I just made up > this simplified version of something at work, where we can't change > the table : both isbn and name MUST be in the table, and what I'm > trying to do is put a CONSTRAINT on the table definition to protect > against user error, by making sure that any entered isbn is only tied > to one book-name in that table. > > Thoughts? > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster -- UC -- Open Source Solutions 4U, LLC 2570 Fleetwood Drive Phone: +1 650 872 2425 San Bruno, CA 94066 Cell: +1 650 302 2405 United States Fax:+1 650 872 2417 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] brain-teaser with CONSTRAINT - any SQL experts?
On Sat, 2005-10-08 at 22:36 -0700, Miles Keaton wrote: > ... both isbn and name MUST be in the table, and what I'm > trying to do is put a CONSTRAINT on the table definition to protect > against user error, by making sure that any entered isbn is only tied > to one book-name in that table. Create a separate table with the two columns name and isbn which are that table's primary key; on the main table, create a foreign key to the new table. -- Oliver Elphick olly@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA Do you want to know God? http://www.lfix.co.uk/knowing_god.html ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
