Thread: Need concrete "Why Postgres not MySQL" bullet list
Folks, I need someone to prepare a standard response for me to send out to inquiries on this topic. I get them a lot. What I'd like is a factual, non-perjorative list of the things which PostgreSQL and the PostgreSQL project have that MySQL does not, with a little bit of explanation by each. Where links can be provided, please do so. Examples: PROCEDURES: Postgres supports stored procedures (as functions) allowing programming in the database for the many tasks which are far more efficient, consistent, and secure done there. Procedures may be written in any of nine different languages, currently, with two more in development. MySQL does not support procedures at all. TRANSACTIONS: blah, blah, blah. MySQL has just begun offering transactions this year, and their solution is largely untested, slow, and suffers from complications with the many different "table types". PostgreSQL's MVCC transaction support, on the other hand, has been in use in production in numerous environments for over six years. Can anyone do this? -- Josh Berkus Aglio Database Solutions San Francisco
In article <200308200839.28230.josh@agliodbs.com>,
Josh Berkus <josh@agliodbs.com> writes:
> PROCEDURES: Postgres supports stored procedures (as functions) allowing
> programming in the database for the many tasks which are far more efficient,
> consistent, and secure done there. Procedures may be written in any of nine
> different languages, currently, with two more in development. MySQL does not
> support procedures at all.
From the MySQL manual:
* With UDF (user-defined functions) one can extend MySQL Server with
both normal SQL functions and aggregates, but this is not yet as
easy or as flexible as in PostgreSQL.
> TRANSACTIONS: blah, blah, blah. MySQL has just begun offering transactions
> this year, and their solution is largely untested, slow...
InnoDB transactions in MySQL are pretty robust and fast. However,
this affects only INSERT/UPDATE/DELETE - not CREATE TABLE etc.
> and suffers from
> complications with the many different "table types".
True. Transactions break unless all tables used are InnoDB.
On Wed, 2003-08-20 at 13:20, Harald Fuchs wrote:
> > and suffers from
> > complications with the many different "table types".
>
> True. Transactions break unless all tables used are InnoDB.
>
Actually the problem is worse than transactions breaking, the problem is
that they don't break and just silently fail you in some circumstances.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Wednesday 20 August 2003 17:39, Josh Berkus wrote: > Folks, > > I need someone to prepare a standard response for me to send out to > inquiries on this topic. I get them a lot. > > What I'd like is a factual, non-perjorative list of the things which > PostgreSQL and the PostgreSQL project have that MySQL does not, Oh dear, this excludes my usual one-item "things to think about when considering what database to use": * PROPER USAGE OF NULL mysql> select * from ai_test where id is null; +----+-------+ | id | txt | +----+-------+ | 1 | hello | +----+-------+ 1 row in set (0.00 sec) ;-). I digress. Off the top of my head, in no particular order: * VIEWS VIEWs are an important element of efficient professional database design, pushing repetitive, often duplicated queries into the backend, increasing the flexibility of an application and reducing the risk of errors. They also enable the encapsulation of table structure, which may change with application development, behind a consistent interface. - MySQL has no support for views, but promises them in a future version, for which no target production date exists: http://www.mysql.com/doc/en/ANSI_diff_Views.html * TRIGGERS Triggers enable predefined actions to be carried out before or after inserts, deletes and updates are performed on tables. This enables automation of many tasks in the database, for example logging specific events such as changes to a table holding accounting data, or checking and modifying a column prior to insertion or update. - MySQL does not support triggers. Implementation is planned: http://www.mysql.com/doc/en/ANSI_diff_Triggers.html * SEQUENCES Often it is useful or necessary to generate a unique number for a row of data, for example for providing a primary key ID. Many databases including PostgreSQL provide sequences - functions for automatically generating unique numbers in predefined increments. - MySQL provides only a very primitive sequence generator, AUTO_INCREMENT, whose behaviour is difficult to modify. It is not possible to explicitly set the current value of a specific AUTO_INCREMENT sequence or an incrementation other than 1. - AUTO_INCREMENT is implemented as SELECT MAX(col) FROM table (see: http://www.mysql.com/doc/en/InnoDB_auto-increment_column.html ) which makes concurrent transactions prone to deadlocks - The use of the NULL value to provoke insertion of the next sequence value means it is impossible to have a sequence on a NULLable column in MySQL. - there can be only one AUTO_INCREMENT column per table * RULES, TYPES, DOMAINS * PROCEDURES in a variety of languages... * DDL - Data definition language (table creation statements etc.) in MySQL are not transaction based and cannot be rolled back. - Some parts of a table definition, although syntactically corrent, maybe ignored without warning. This applies particularly to syntax such as CREATE TABLE my_table ( id INT NOT NULL PRIMARY KEY, fkey_id INT NOT NULL REFERENCES other_table(id) ) TYPE=InnoDB See: http://www.mysql.com/doc/en/ANSI_diff_Foreign_Keys.html - MySQL may, at its discretion, silently alter column specifications. See: http://www.mysql.com/doc/en/Silent_column_changes.html - MySQL only permits constants as default values not functions or expressions. See: http://www.mysql.com/doc/en/CREATE_TABLE.html This makes it impossible to provide default values like this: CREATE TABLE deftest ( id INT, date_at_creation TEXT DEFAULT 'The date is '|| to_char('dd-mm-yyyy', now()) ); * GENUINE REFERENTIAL INTEGRITY An essential part of the relational model is the ability to create foreign keys, which define relationships between tables. Naturally only values which exist in the referenced table can be used in a foreign key column. PostgreSQL has provided integrated foreign key support since (find out when). - In MySQL foreign keys are an "optional extra" and are only available when the InnoDB table type is specified. - Not all MySQL server installations are configured to provide InnoDB support, e.g. ISP-run servers. - despite the implementation of foreign keys with InnoDB tables, MySQL does not provide robust referential integrity. Under certain circumstances MySQL will insert into or permit the presence of values in a foreign key which are not present in the table referred to. For example, if a foreign key column can contain null values, and the column's definition is changed to NOT NULL, MySQL will insert 0 (zero) into the previously NULL columns, even if the column referred to in a different table does not contain 0. - No ON UPDATE ... support * RIGOROUS FAILURE TESTING When developing a database, and in day-to-day operation, it is essential that erroneous statements fail with a specific warning to prevent violations of data integrity. - in many cases where a statement would be expected to fail, MySQL will silently insert default values. For example, when (mistakenly) inserting an integer 1 into an ENUM field, MySQL will insert a string containing '0' rather than raise an error. * DICTIONARY BASED FULL-TEXT INDEXING Although SQL provides several methods of searching for patterns in text fields (LIKE, regexes), these do not provide sufficient functionality for more complex searches, e.g. as used by search engines. - MySQL provides a builtin index type FULLTEXT, which allows keyword searches. In contrast to PostgreSQL's tsearch2 functionality, this does not provide for advanced natural language based searches using features such as dictionary lookups and stemming. * LICENSING - MySQL is available as "open source", but depending on useage not always with an open source license. MySQL's licencing conditions are subject to change. - PostgreSQL is available under a BSD-style licence to all users whether commercial or private. I can take the above and any further additions and flesh it out into a more readable list (if noone else wants to). I have a project at the moment which will probably be marketed as a MySQL-compatible application ("it's what the users have"), though I am prototyping it in PostgreSQL, and I'm collecting a lot of interesting insights... Ian Barwick barwick@gmx.net
Ian,
do you use any specific tools to prototype applications designed for
PostgreSQL?
Anastasios
> I can take the above and any further additions and flesh it out
> into a more readable list (if noone else wants to). I have a
> project at the moment which will probably be marketed as
> a MySQL-compatible application ("it's what the users have"),
> though I am prototyping it in PostgreSQL, and I'm collecting
> a lot of interesting insights...
>
> Ian Barwick
> barwick@gmx.net
> Oh dear, this excludes my usual one-item "things to think about
> when considering what database to use":
>
> * PROPER USAGE OF NULL
>
> mysql> select * from ai_test where id is null;
> +----+-------+
> | id | txt |
> +----+-------+
> | 1 | hello |
> +----+-------+
> 1 row in set (0.00 sec)
>
> ;-). I digress. Off the top of my head, in no particular order:
You're not trying hard enough:
mysql> create table test3 (a date);
Query OK, 0 rows affected (0.00 sec)
mysql> insert into test3 values (-1);
Query OK, 1 row affected (0.01 sec)
mysql> insert into test3 values ('1996-02-31');
Query OK, 1 row affected (0.00 sec)
mysql> insert into test3 values ('1996-67-31');
Query OK, 1 row affected (0.00 sec)
mysql> select * from test3;
+------------+
| a |
+------------+
| 0000-00-00 |
| 1996-02-31 |
| 0000-00-00 |
+------------+
3 rows in set (0.00 sec)
I find that even funnier...
Chris
On 21 Aug 2003 at 0:22, Ian Barwick wrote: > * DDL > - Data definition language (table creation statements etc.) in MySQL > are not transaction based and cannot be rolled back. Just wondering, what other databases has transactable DDLs? oracle seems to have autonomous transactions which is arthogonal. If we are going to compare it, we are going to need it against other databases as well. Personally I find transactable DDL's a big plus of postgresql. It allows real funcky application design at times..:-) Bye Shridhar -- drug, n: A substance that, injected into a rat, produces a scientific paper.
Shridhar Daithankar wrote: >On 21 Aug 2003 at 0:22, Ian Barwick wrote: > > >>* DDL >>- Data definition language (table creation statements etc.) in MySQL >>are not transaction based and cannot be rolled back. >> >> > >Just wondering, what other databases has transactable DDLs? oracle seems to >have autonomous transactions which is arthogonal. > M$ SQL2000 has (and previous versions had too, I believe) Regards, Andreas
On Thu, 21 Aug 2003 14:45:03 +0530, "Shridhar Daithankar" <shridhar_daithankar@persistent.co.in> wrote: >Just wondering, what other databases has transactable DDLs? Firebird. Servus Manfred
On 20 Aug 2003, Harald Fuchs wrote: > In article <200308200839.28230.josh@agliodbs.com>, > Josh Berkus <josh@agliodbs.com> writes: > > > PROCEDURES: Postgres supports stored procedures (as functions) allowing > > programming in the database for the many tasks which are far more efficient, > > consistent, and secure done there. Procedures may be written in any of nine > > different languages, currently, with two more in development. MySQL does not > > support procedures at all. > > >From the MySQL manual: > * With UDF (user-defined functions) one can extend MySQL Server with > both normal SQL functions and aggregates, but this is not yet as > easy or as flexible as in PostgreSQL. > > > TRANSACTIONS: blah, blah, blah. MySQL has just begun offering transactions > > this year, and their solution is largely untested, slow... > > InnoDB transactions in MySQL are pretty robust and fast. However, > this affects only INSERT/UPDATE/DELETE - not CREATE TABLE etc. Well, I wouldn't say that they're that robust. Try this: create innodb table begin transaction; insert 1,000,000 rows; rollback; wait for years for the rollback to finish. From the MySQL manual: http://www.mysql.com/documentation/mysql/bychapter/manual_Table_types.html#Innodb_tuning QUOTE 8: # Beware of big rollbacks of mass inserts: InnoDB uses the insert buffer to save disk I/O in inserts, but in a corresponding rollback no such mechanism is used. A disk-bound rollback can take 30 times the time of the corresponding insert. Killing the database process will not help because the rollback will start again at the database startup. The only way to get rid of a runaway rollback is to increase the buffer pool so that the rollback becomes CPU-bound and runs fast, or delete the whole InnoDB database. ENDQUOTE It's obvious that innodb transactions aren't meant to handle large data sets and rollback well, and the compromise here, like in all of MySQL, tends towards "hoping for the best" and benchmarking that particular aspect. > > and suffers from > > complications with the many different "table types". > > True. Transactions break unless all tables used are InnoDB. And, more importantly, they break silently, or you find out too late (i.e. oh by the way, some of those rows couldn't be rolled back...)
Ian's list is excellent. I would like to add to the point about pl languages. Use the right tool for the job: Procedure may be written in tcl, plpgsql, perl, python, R (statistics) so you can use the right tool for the job at hand as well as leverage your existing knowledge of a given scripting language. It would help to solidify our specific examples of failures if the version and platform of mysql is included. Clarifications with postgresql functionality working correctly may be appropriate in some cases (also include version & platform). At oscon, the mysql guys were fighting "old" rumors. As they glob on functionality to try to catch up to 1990 technology, they will assert that "we have transactions now!", etc. By including the version and platform *and* sticking only to the facts, we can forstall a few flames. elein On Wed, Aug 20, 2003 at 08:39:28AM -0700, Josh Berkus wrote: > Folks, > > I need someone to prepare a standard response for me to send out to inquiries > on this topic. I get them a lot. > > What I'd like is a factual, non-perjorative list of the things which > PostgreSQL and the PostgreSQL project have that MySQL does not, with a little > bit of explanation by each. Where links can be provided, please do so. > Examples: > > PROCEDURES: Postgres supports stored procedures (as functions) allowing > programming in the database for the many tasks which are far more efficient, > consistent, and secure done there. Procedures may be written in any of nine > different languages, currently, with two more in development. MySQL does not > support procedures at all. > > TRANSACTIONS: blah, blah, blah. MySQL has just begun offering transactions > this year, and their solution is largely untested, slow, and suffers from > complications with the many different "table types". PostgreSQL's MVCC > transaction support, on the other hand, has been in use in production in > numerous environments for over six years. > > Can anyone do this? > > -- > Josh Berkus > Aglio Database Solutions > San Francisco > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match >
Re: [GENERAL] [HACKERS] Need concrete "Why Postgres not MySQL" bullet list
From
Manfred Koizar
Date:
On Thu, 21 Aug 2003 15:05:52 +0200, I wrote: >>Just wondering, what other databases has transactable DDLs? > >Firebird. Stop! I withdraw that statement. I must have mis-read some feature list :-( Tests with InterBase 6 showed that you can change metadata within a transaction, but when you ROLLBACK, metadata changes persist. Servus Manfred
On Thursday 21 August 2003 21:30, Manfred Koizar wrote: > On Thu, 21 Aug 2003 15:05:52 +0200, I wrote: > >>Just wondering, what other databases has transactable DDLs? > > > >Firebird. > > Stop! I withdraw that statement. I must have mis-read some feature > list :-( > > Tests with InterBase 6 showed that you can change metadata within a > transaction, but when you ROLLBACK, metadata changes persist. Aha. I was just about to ask about that, because I was experimenting with a 1.5 beta version without success. Doesn't seem to work there (though as I have little experience and virtually no docs I might be missing something). Ian Barwick barwick@gmx.net
On Thursday 21 August 2003 11:15, Shridhar Daithankar wrote: > On 21 Aug 2003 at 0:22, Ian Barwick wrote: > > * DDL > > - Data definition language (table creation statements etc.) in MySQL > > are not transaction based and cannot be rolled back. > > Just wondering, what other databases has transactable DDLs? oracle seems to > have autonomous transactions which is arthogonal. DB2 8.1 seems to support transaction-capable DDL. At least, a rollback following a CREATE TABLE causes the table to disappear. Haven't gone into it in any depth. Ian Barwick barwick@gmx.net
On Thursday 21 August 2003 00:44, Anastasios Hatzis wrote: > Ian, > > do you use any specific tools to prototype applications designed for > PostgreSQL? 'Fraid not. Apart from a pen and a piece of paper ;-). I find Postgres very "ergonomical" to develop with, particularly in the earlier stages of an application: transaction-capable DDL makes design changes easy to test without risk of messing up the database; strong referential integrity helps develop robust applications (having the app fail on the slightest hint of bad data makes bugs in the app much easier to find) and psql with its tab-completion and readline support has gone a long way to saving me from carpal tunnel syndrome. Ian Barwick barwick@gmx.net
On Thursday 21 August 2003 20:16, elein wrote: > Ian's list is excellent. > > I would like to add to the point about pl languages. > > Use the right tool for the job: > Procedure may be written in tcl, plpgsql, perl, > python, R (statistics) so you can use the right tool > for the job at hand as well as leverage your > existing knowledge of a given scripting language. Good point. I will try and get a working draft together by the start of next week. > It would help to solidify our specific examples > of failures if the version and platform of mysql > is included. Yup. I have compiled a long list of behavioural oddities for my own reference; I've researched many of these in the MySQL documentation (to make sure I'm not seeing things), and an astounding number are actually documented and show no signs of going away, even in the 4.x series. I will install a 4.1 alpha (?) version just to be on the safe side, as this is being touted as "the will-MySQL-make-it-into-the enterprise-league version" (i.e. the version with sub-selects). > Clarifications with postgresql > functionality working correctly may be appropriate > in some cases (also include version & platform). Here we need to emphasize the progress made in 7.3 / 7.4, I get the impression a lot of people still see Postgres as the "database without the DROP COLUMN functionality"... Ian Barwick barwick@gmx.net
Hi all! Can someone explain me why is it usefull if the table created in transaction disapears on rollback? Anyway the progress db supports it, at least the version 9. The other question: why is mysql enemy? Isn`t it just another RDBMS? Thanks, Laszlo On Thu, 21 Aug 2003, Ian Barwick wrote: > On Thursday 21 August 2003 11:15, Shridhar Daithankar wrote: > > On 21 Aug 2003 at 0:22, Ian Barwick wrote: > > > * DDL > > > - Data definition language (table creation statements etc.) in MySQL > > > are not transaction based and cannot be rolled back. > > > > Just wondering, what other databases has transactable DDLs? oracle seems to > > have autonomous transactions which is arthogonal. > > DB2 8.1 seems to support transaction-capable DDL. At least, a rollback > following a CREATE TABLE causes the table to disappear. Haven't gone > into it in any depth. > > > Ian Barwick > barwick@gmx.net > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
> Can someone explain me why is it usefull if the table created in > transaction disapears on rollback? Because then you can write big scripts like we do at work to install a new feature in the live database. Such a script might create two new tables, add columns to existing tables, drop and recreate some foreign keys, etc. What you do is to test it you go 'begin;' and then execute the script. If it all worked, commit, else rollback and fix the script. Repeat until you get it right. Chris
Re: [GENERAL] [HACKERS] Need concrete "Why Postgres not MySQL" bullet list
From
"Shridhar Daithankar"
Date:
On 21 Aug 2003 at 21:30, Manfred Koizar wrote: > On Thu, 21 Aug 2003 15:05:52 +0200, I wrote: > >>Just wondering, what other databases has transactable DDLs? > > > >Firebird. > > Stop! I withdraw that statement. I must have mis-read some feature > list :-( > > Tests with InterBase 6 showed that you can change metadata within a > transaction, but when you ROLLBACK, metadata changes persist. Well, isql documentation mentions that DDLs don't go to database unless you commit and autoddl parameter defaults to true. Looks like there definition of transactable does not include a rollback case. Oops! BTW any comments on storing an entire database in single file? I don't trust any file system for performance and data integrity if I have single 100GB file. I would rather have multiple of them.. Bye Shridhar -- Moore's Constant: Everybody sets out to do something, and everybody does something, but no one does what he sets out to do.
On 22 Aug 2003 at 8:30, Hornyak Laszlo wrote: > Can someone explain me why is it usefull if the table created in > transaction disapears on rollback? Imagine you are trying to duplicate a table but succeed halfway only? More importantly all catalog changes are transaction safe in postgresql. Not only tables, but indexes, views, functions, triggers, rules and schemas are transaction safe as well. IMO that's a big feature list.. > Anyway the progress db supports it, at least the version 9. > The other question: why is mysql enemy? Isn`t it just another RDBMS? First of all it's not RDBMS. Any product that exposes details of underlying storage mechanism can not qualify as RDBMS. Innodb only has transactions.. Wow.. Secondly it's not enemy. At the most competitor if you in business of selling postgresql and an overhyped product overall.. Just my opinion.. Bye Shridhar -- Canada Bill Jones's Motto: It's morally wrong to allow suckers to keep their money.Canada Bill Jones's Supplement: A Smith and Wesson beats four aces.
On Friday 22 August 2003 07:40, Christopher Kings-Lynne wrote: > > Can someone explain me why is it usefull if the table created in > > transaction disapears on rollback? > > Because then you can write big scripts like we do at work to install a new > feature in the live database. Such a script might create two new tables, > add columns to existing tables, drop and recreate some foreign keys, etc. > What you do is to test it you go 'begin;' and then execute the script. If > it all worked, commit, else rollback and fix the script. Repeat until you > get it right. Exactly - I'm currently finalising a schema in conjunction with a client who's working with some telecoms control equipment. Being able to modify tables and copy-forward the data inside a transaction is very useful. -- Richard Huxton Archonet Ltd
In article <Pine.LNX.4.21.0308220805290.11798-100000@tiger.tigrasoft.hu>, Hornyak Laszlo <kocka@tigrasoft.hu> writes: > Hi all! > Can someone explain me why is it usefull if the table created in > transaction disapears on rollback? > Anyway the progress db supports it, at least the version 9. > The other question: why is mysql enemy? Isn`t it just another RDBMS? Your second question is answered by someone in a recent posting on the MySQL mailing list: > As an Oracle DBA (I'm one myself), InnoDB will give you "close to Oracle" > features. > As an FYI, we also spent alot of time looking @ Postres and SAPDB. Postgres > is a great database engine, and would be very adequate if it didn't have one > significant missing feature - there is no replication or standby support > unless you buy an expensive licence (which brings the cost close to that of > Oracle); we need the high-availability of clusters and replication. Both > Postgres and MySQL have great support via their mailing lists, but once in a > while, the people on the Postgres mailing list decide to kick MySQL around a > bit; I think they have an inferiority complex. :-)
Hornyak Laszlo wrote: > Hi all! > > Can someone explain me why is it usefull if the table created in > transaction disapears on rollback? > Anyway the progress db supports it, at least the version 9. > The other question: why is mysql enemy? Isn`t it just another RDBMS? Go to http://www.mysql.com, type "postgresql" into the search field (top right corner) and read through some of the links. Especially stuff like the subsections of http://www.mysql.com/doc/en/Compare_PostgreSQL.html Then go to http://www.postgresql.org and try to find similar FUD. You will rather find something like this: http://developer.postgresql.org/~petere/comparison.html This exercise will tell you who considers whom "enemy" and why some of us just "dislike" MySQL and their understanding of "fair". Jan > > Thanks, > Laszlo > > On Thu, 21 Aug 2003, Ian Barwick wrote: > >> On Thursday 21 August 2003 11:15, Shridhar Daithankar wrote: >> > On 21 Aug 2003 at 0:22, Ian Barwick wrote: >> > > * DDL >> > > - Data definition language (table creation statements etc.) in MySQL >> > > are not transaction based and cannot be rolled back. >> > >> > Just wondering, what other databases has transactable DDLs? oracle seems to >> > have autonomous transactions which is arthogonal. >> >> DB2 8.1 seems to support transaction-capable DDL. At least, a rollback >> following a CREATE TABLE causes the table to disappear. Haven't gone >> into it in any depth. >> >> >> Ian Barwick >> barwick@gmx.net >> >> >> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 2: you can get off all lists at once with the unregister command >> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >> > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
<off> Yep, I know, but that is not a reason. :) </off> Laci On Fri, 22 Aug 2003, Jan Wieck wrote: > Hornyak Laszlo wrote: > > > Hi all! > > > > Can someone explain me why is it usefull if the table created in > > transaction disapears on rollback? > > Anyway the progress db supports it, at least the version 9. > > The other question: why is mysql enemy? Isn`t it just another RDBMS? > > Go to http://www.mysql.com, type "postgresql" into the search field (top > right corner) and read through some of the links. Especially stuff like > the subsections of > > http://www.mysql.com/doc/en/Compare_PostgreSQL.html > > Then go to http://www.postgresql.org and try to find similar FUD. You > will rather find something like this: > > http://developer.postgresql.org/~petere/comparison.html > > This exercise will tell you who considers whom "enemy" and why some of > us just "dislike" MySQL and their understanding of "fair". > > > Jan > > > > > Thanks, > > Laszlo > > > > On Thu, 21 Aug 2003, Ian Barwick wrote: > > > >> On Thursday 21 August 2003 11:15, Shridhar Daithankar wrote: > >> > On 21 Aug 2003 at 0:22, Ian Barwick wrote: > >> > > * DDL > >> > > - Data definition language (table creation statements etc.) in MySQL > >> > > are not transaction based and cannot be rolled back. > >> > > >> > Just wondering, what other databases has transactable DDLs? oracle seems to > >> > have autonomous transactions which is arthogonal. > >> > >> DB2 8.1 seems to support transaction-capable DDL. At least, a rollback > >> following a CREATE TABLE causes the table to disappear. Haven't gone > >> into it in any depth. > >> > >> > >> Ian Barwick > >> barwick@gmx.net > >> > >> > >> > >> > >> ---------------------------(end of broadcast)--------------------------- > >> TIP 2: you can get off all lists at once with the unregister command > >> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > >> > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > > > -- > #======================================================================# > # It's easier to get forgiveness for being wrong than for being right. # > # Let's break this rule - forgive me. # > #================================================== JanWieck@Yahoo.com # > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org >
Surveys & Studies: FLOSS - Usage of Free/Libre Open Source Software (PostgreSQL, etc.)
From
Anastasios Hatzis
Date:
There is an interesting report (in English) about the use of free Open-Source software in companies and public institutions in Germany, UK and Sweden. (As Germany is one of the most important and largest markets for Open-Source software) This FLOSS report covers to some extend specific figures about Open-Source DBMS, reasons why organizations have decided for OS DBMS, market shares of OSS DBMS, etc. - PostgreSQL and MySQL are mentioned too (see chapter 5.1.2 OSS used for databases, Page 37+). The report has been made by Berlecon Research (http://www.berlecon.de) in 2002, financed by the European Commission. Maybe you already know this report, but for them who do not, I provide this report as PDF temporarily at following URL: http://www.go-gen.com/tmp/FLOSS1-Usage_of_Free_Open_Source.pdf Hopefully, these information may be useful for better understanding the needs of our customers, or the promotion of PostgreSQL. Have a nice W/E Anastasios