Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On 8 Aug 2002, Hannu Krosing wrote: The main difference (in the inheritance part) is that a relation does not have one fixed set of fields, but can have any additional fields added in inherited tables and still be part of to the base table as well. This is trivial to do with a view. Actually I am not against ripping out the current broken implementation, but not before there has been a new, correct model available for at least two releses, so that people have had time to switch over. So in other words, you want to let people use broken stuff, rather than switch to another method, currently available, that has all of the functionality but is not broken. I guess that's an opinion, all right. VIEWs are broken too, in the sense that you can't insert into them without doing some hard work. Views are missing functionality. That is rather different from making other tables lie about what they contain, essentially destroying the requested data integrity. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Curt Sampson wrote: On 8 Aug 2002, Hannu Krosing wrote: The main difference (in the inheritance part) is that a relation does not have one fixed set of fields, but can have any additional fields added in inherited tables and still be part of to the base table as well. This is trivial to do with a view. And views of this sort are trivial to do using PG's OO extensions. I think I see a trend in this thread. Why not give it up, dude? -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Thu, 8 Aug 2002, Don Baccus wrote: And views of this sort are trivial to do using PG's OO extensions. So long as you don't mind them being broken, yeah. But hell, when someone asks for a unique constraint, they probably don't really mean it, do they? And what's wrong with multiple records with the same primary key? It's clear to me now I've been working from the wrong direction; we should leave the OO stuff and delete the relational stuff from the database instead. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Curt Sampson wrote: On Thu, 8 Aug 2002, Don Baccus wrote: And views of this sort are trivial to do using PG's OO extensions. So long as you don't mind them being broken, yeah. But hell, when someone asks for a unique constraint, they probably don't really mean it, do they? Good grief, we all agree that they're currently broken and need to be fixed someday. Give it up. You're being a boor. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL
On 29 Jul 2002, Stephen Deasey wrote: Table inheritance offers data model extensibility. New (derived) tables can be added to the system, and will work with existing code that opperates on the base tables, without having to hack up all the code. And why does this not work with the standard relational mechanism? (Where a derived table would be just another table with a foreign key pointing back to the base table.) cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On 2 Aug 2002, Hannu Krosing wrote: On Fri, 2002-08-02 at 12:15, Curt Sampson wrote: On 2 Aug 2002, Hannu Krosing wrote: Could you brief me why do they discourage a syntactical frontent to a feature that is trivially implemented ? What's the point of adding it? It's just one more thing to learn. You don't have to learn it if you don't want to. But once you do, you have a higher level way of expressing a whole class of models. Perhaps this is the problem. I disagree that it's a higher level. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Sat, 2002-08-03 at 16:32, Curt Sampson wrote: On 2 Aug 2002, Hannu Krosing wrote: On Fri, 2002-08-02 at 12:15, Curt Sampson wrote: On 2 Aug 2002, Hannu Krosing wrote: Could you brief me why do they discourage a syntactical frontent to a feature that is trivially implemented ? What's the point of adding it? It's just one more thing to learn. You don't have to learn it if you don't want to. But once you do, you have a higher level way of expressing a whole class of models. Perhaps this is the problem. I disagree that it's a higher level. I don't mean morally higher ;) Just more concise and easier to grasp, same as VIEW vs. TABLE + ON xxx DO INSTEAD rules. With INSTEAD rules you can do more than a VIEW does, but when all you want is a VIEW, then it is easier to define a VIEW, thus VIEW is a higher level construct than TABLE + ON xxx DO INSTEAD That is the same way that C is higher than ASM and ASM is higher than writing code directly using hex editor. -- Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On 3 Aug 2002, Hannu Krosing wrote: On Sat, 2002-08-03 at 16:32, Curt Sampson wrote: On 2 Aug 2002, Hannu Krosing wrote: Perhaps this is the problem. I disagree that it's a higher level. I don't mean morally higher ;) Just more concise and easier to grasp, same as VIEW vs. TABLE + ON xxx DO INSTEAD rules. That's because we don't do a good job of implementing updatable views. Views ought to be as fully updatable as possible given the definition, without having to define rules for doing this. Simple views such as CREATE TABLE tab1 ( id int, foo text ) CREATE TABLE tab2 ( id int, bar text ) CREATE VIEW something AS SELECT tab1.id, tab1.foo, tab2.bar FROM tab1, tab2 WHERE tab1.id = tab2.id ought to be completely updatable without any special rules. For further info see the detailed discussion of this in Date's database textbook. That is the same way that C is higher than ASM and ASM is higher than writing code directly using hex editor. No, this is the same way that Smalltalk is higher than Lisp. (I.e., it isn't.) cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Thu, 2002-08-01 at 22:39, Curt Sampson wrote: On 1 Aug 2002, Greg Copeland wrote: For some reason, many of the developers are under the impression that even if code is never touched, it has a very high level of effort to keep it in the code base. That is, of course, completely untrue. Where does this of course come from? I've been programming for quite a while now, and in my experience every line of code costs you something to maintain. Please re-read my statement. Your assertion and my statement are by no means exclusionary. Of course was correctly used and does correctly apply, however, it doesn't appear it was correctly comprehended by you as it applied in context. I agree with your statement of, ...every line of code costs you something to maintain... which in no way, shape, or form contradicts my statement of, ...it has a very high level of effort...of course not Fact is, if code which is never touched and requires a very level of effort to maintain, chances are you screwed up somewhere. Hopefully we can agree that ...costs you something... does not have to mean, ...very high level of effort... As long as there's any interaction with other parts of the system, you have to test it regularly, even if you don't need to directly change it. No one said otherwise. Perhaps you were replying to someone else?! :) That said, if you've been doing regular work on postgres code base and you say that it's cheap to maintain, I'll accept that. Please re-read my statement. In my mind, this was implicately understood from the statement I made. Shesh...sure hope I remembered to dot all my i's... Greg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Matthew Tedder [EMAIL PROTECTED] wrote: For most web sites MySQL seems to work fine, but overall PostgreSQL offers more capabilites so why build upon a limited base such as MySQL? Does anyone here have any idea as to why so many people select MySQL when both systems are open sourced? Some people working on win32 platforms, and mysql easy install on win32. Just for starting on use databases in soft. PgSQL easy-install on *unix-systems (mostly..:)), but on win32 ..it's hard..:( IMHO. -- Best regards, KVN. PHP4You (http://php4you.kiev.ua/) PEAR [ru] (http://pear.php.net/manual/ru/) mailto:[EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: 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: [HACKERS] Why is MySQL more chosen over PostgreSQL
Curt Sampson wrote: I'm still waiting to find out just what advantage table inheritance offers. I've asked a couple of times here, and nobody has even started to come up with anything. Table inheritance offers data model extensibility. New (derived) tables can be added to the system, and will work with existing code that opperates on the base tables, without having to hack up all the code. Inherited indexes etc. would be nice, but it's the inability to have referential integrity against a base table that picks up child table rows that makes the current implementation useles. I would rather see it fixed than junked, and better yet extended. It would be incredibly useful in real-world projects with complex data models like OpenACS. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Well, if you also have soundcard_products, in your example you could have a product which is both a networkcard AND a soundcard. No way to restrict that a product can be only one 'subclass' at a time... If you can make that restriction using the relational model, you can do the same as with subclasses. But afaict that is very hard to do... Perhaps I'm mistaken, but it looks to me as if the relational model still holds quite cleanly. CREATE TABLE products ( id int4 primary key, name text ); CREATE TABLE soundcard ( prod_id int4 REFERENCES products(id), some_feature BOOLEAN); CREATE VIEW soundcard_v AS SELECT * FROM products, soundcard WHERE products.id = soundcard.prod_id; CREATE TABLE networkcard ( prod_id int4 REFERENCES products(id), hundred_base_t BOOLEAN); CREATE VIEW networkcard_v AS SELECT * FROM products, networkcard WHERE products.id = networkcard.prod_id; Now, to get the networkcard/soundcard combos, you just need to do: SELECT * FROM soundcard_v, networkcard_v WHERE soundcard_v.id = networkcard_v.id; For what it's worth, I didn't make any mistakes writing it up the first time. It most certainly fits my brain well and seems simple and clean. I am not advocating that we remove inheritance, but I (so far) agree with Curt that it's pretty useless. Regards, Jeff ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Fri, 2002-08-02 at 13:53, Jeff Davis wrote: Well, if you also have soundcard_products, in your example you could have a product which is both a networkcard AND a soundcard. No way to restrict that a product can be only one 'subclass' at a time... If you can make that restriction using the relational model, you can do the same as with subclasses. But afaict that is very hard to do... Perhaps I'm mistaken, but it looks to me as if the relational model still holds quite cleanly. CREATE TABLE products ( id int4 primary key, name text ); CREATE TABLE soundcard ( prod_id int4 REFERENCES products(id), some_feature BOOLEAN); CREATE VIEW soundcard_v AS SELECT * FROM products, soundcard WHERE products.id = soundcard.prod_id; CREATE TABLE networkcard ( prod_id int4 REFERENCES products(id), hundred_base_t BOOLEAN); CREATE VIEW networkcard_v AS SELECT * FROM products, networkcard WHERE products.id = networkcard.prod_id; Now, to get the networkcard/soundcard combos, you just need to do: SELECT * FROM soundcard_v, networkcard_v WHERE soundcard_v.id = networkcard_v.id; For what it's worth, I didn't make any mistakes writing it up the first time. It most certainly fits my brain well and seems simple and clean. Yup, you've basically done it -- but you still need the permissions lines (soundcard people shouldn't be able to modify networkcard products -- but rules on the views could accomplish that). create table product(prod_id int4 primary key); create table networkcard(hundred_base_t boolean) inherits(product); create table soundcard(some_feature boolean) inherits(product); create table something(some_feature integer) inherits(product); My favorite (and regularly abused): create table package_deal(package_price) inherits (product, networkcard, soundcard, something); Poor examples as noone would make a sellable package that way, but it shows how it is simply shorter to do. New 'product' consists of a networkcard, soundcard, and something -- always. Nobody is saying that: ESC:%s/aba/wo/g is a real easy way to know to replace all occurrences of 'aba' with 'wo', and there are lots of other ways of doing it -- but if you happen to know it, then it certainly makes life easier but is not a very portable command set :) Views don't do much else but make life easier. Putting the SQL into the original queries is just as effective and slightly lower overhead. Inheritance for me makes life a little bit easier in certain places. It's also easier for the programmers to follow than a wackload of views and double inserts. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Fri, 2 Aug 2002, Tom Lane wrote: Greg Copeland [EMAIL PROTECTED] writes: I seem to find this argument a lot on the list here. For some reason, many of the developers are under the impression that even if code is never touched, it has a very high level of effort to keep it in the code base. That is, of course, completely untrue. FWIW, I did not notice any of the core developers making that case. As far as I'm concerned, any patch to remove inheritance will be rejected out of hand. It's not costing us anything significant to maintain as-is, and there are a goodly number of people using it. Extending it (eg, making cross-table indexes to support inherited uniqueness constraints) is a different kettle of fish --- but until someone steps up to the plate with an implementation proposal, it's rather futile to speculate what that might cost. In the meantime, the lack of any such plan is no argument for removing the functionality we do have. Definitely concur ... in fact, didn't someone recently do some work to improve our inheritance code, as it wasn't 'object enough' for them? Isn't inheritance kinda one of those things that is required in order to be consider ourselves ORBDMS, which we do classify our selves as being? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Fri, 2 Aug 2002, Marc G. Fournier wrote: Isn't inheritance kinda one of those things that is required in order to be consider ourselves ORBDMS, which we do classify our selves as being? Well, it depends on what you call an ORDBMS. By the standards of Date and Darwen in _The Third Manifesto_, table inheritance is not required and is in fact discouraged as a feature trivially implemented with views, foreign keys and constraints. (Though that does not mean that posgresql currently has an implementation of these that will make it trivial.) cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Fri, 2002-08-02 at 08:55, Curt Sampson wrote: On Fri, 2 Aug 2002, Marc G. Fournier wrote: Isn't inheritance kinda one of those things that is required in order to be consider ourselves ORBDMS, which we do classify our selves as being? Well, it depends on what you call an ORDBMS. By the standards of Date and Darwen in _The Third Manifesto_, Is _The Third Manifesto_ available online ? table inheritance is not required and is in fact discouraged as a feature trivially implemented with views, foreign keys and constraints. (Though that does not mean that posgresql currently has an implementation of these that will make it trivial.) Could you brief me why do they discourage a syntactical frontent to a feature that is trivially implemented ? If it is just views. foreign keys and constraints anyway, it should not add compexity to implementation. OTOH, stating explicitly what you mean, can give the system extra hints for making good optimisation decisions. - Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Fri, 2002-08-02 at 05:39, Curt Sampson wrote: Because SQL99 is non-relational in many ways, so I guess they figured making it non-relational in one more way can't hurt. I mean come on, this is a language which started out not even relationally complete! Could you point me to some pure relational languages ? Preferrably not pure academic at the same time ;) BTW, what other parts of SQL do you consider non-relational (and thus candidates for dropping) ? - Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On 2 Aug 2002, Hannu Krosing wrote: Is _The Third Manifesto_ available online ? No. It's a book, and not a terribly small one, either. http://www.amazon.com/exec/obidos/ASIN/0201709287/ Could you brief me why do they discourage a syntactical frontent to a feature that is trivially implemented ? What's the point of adding it? It's just one more thing to learn. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On 2 Aug 2002, Hannu Krosing wrote: Could you point me to some pure relational languages ? Preferrably not pure academic at the same time ;) The QUEL and PostQUEL languages used in Ingres and the old Postgres were rather more relational than SQL. BTW, what other parts of SQL do you consider non-relational (and thus candidates for dropping) ? I have nothing particular in mind right now. Also, note that merely being non-relational does not make a language element a candidate for dropping. If lots of other databases implement a feature, it would be silly to destroy compatability for the sake of theory. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Fri, 2002-08-02 at 12:15, Curt Sampson wrote: On 2 Aug 2002, Hannu Krosing wrote: Is _The Third Manifesto_ available online ? No. It's a book, and not a terribly small one, either. http://www.amazon.com/exec/obidos/ASIN/0201709287/ Could you brief me why do they discourage a syntactical frontent to a feature that is trivially implemented ? What's the point of adding it? It's just one more thing to learn. You don't have to learn it if you don't want to. But once you do, you have a higher level way of expressing a whole class of models. Your argument can as well be used against VIEWs - whats the point of having them, when they can trivially be implemented using ON XXX DO INSTEAD rules. -- Hannu ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
* Hannu Krosing [EMAIL PROTECTED] [020802 06:32]:
Your argument can as well be used against VIEWs - whats the point of
having them, when they can trivially be implemented using ON XXX DO
INSTEAD rules.
Well, at least on PostgreSQL it makes a difference. We allow views to
have permissions granted to them independent of the underlying tables.
It a nice , distinguishing feature. What other database allows you
to grant one person access to a subset of the colums of a table as
well as a subset of the rows?
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Thu, 2002-08-01 at 23:30, Tom Lane wrote: Greg Copeland [EMAIL PROTECTED] writes: I seem to find this argument a lot on the list here. For some reason, many of the developers are under the impression that even if code is never touched, it has a very high level of effort to keep it in the code base. That is, of course, completely untrue. FWIW, I did not notice any of the core developers making that case. I've seen it used a lot. In many cases, it's asserted with nothing to support it other than the fact that they are a core developer, however, these assertions are often given against unspecified and undeveloped code, so, it makes such an assertion invalid. Greg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Greg Copeland [EMAIL PROTECTED] writes: On Thu, 2002-08-01 at 23:30, Tom Lane wrote: FWIW, I did not notice any of the core developers making that case. I've seen it used a lot. Perhaps my meaning wasn't clear: I meant that no one who's familiar with the code base has made that argument against inheritance. It doesn't impact enough of the code to be a maintenance problem. There is quite a bit of inheritance code in tablecmds.c, and one or two other files, but overall it's a very small issue. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Hi And what's the problem with networkcard_products being a separate table that shares a key with the products table? CREATE TABLE products (product_id int, ...) CREATE TABLE networkcard_products_data (product_id int, ...) CREATE VIEW networkcard_products AS SELECT products.product_id, ... FROM products JOINT networkcard_products_data USING (product_id) What functionality does table inheritance offer that this traditional relational method of doing things doesn't? Well, if you also have soundcard_products, in your example you could have a product which is both a networkcard AND a soundcard. No way to restrict that a product can be only one 'subclass' at a time... If you can make that restriction using the relational model, you can do the same as with subclasses. But afaict that is very hard to do... Sander. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Tue, 2002-07-30 at 14:54, Hannu Krosing wrote: On Tue, 2002-07-30 at 16:00, Curt Sampson wrote: On 30 Jul 2002, Hannu Krosing wrote: On Tue, 2002-07-30 at 14:51, Adrian 'Dagurashibanipal' von Bidder wrote: Bruce Momjian: It causes too much complexity in other parts of the system. That's one reason. Seems like somewhat valid reason. But still not enough to do a lot of work _and_ annoy a lot of existing users :) It's almost unquestionably more work to maintain than to drop. Dropping support for it is a one-time operation. Maintaining it is an ongoing expense. I would not rush to drop advanced features, as they may be hard to put back later. If they stay in, even in broken form, then there wont be nearly as much patches which make fixing them harder. I seem to find this argument a lot on the list here. For some reason, many of the developers are under the impression that even if code is never touched, it has a very high level of effort to keep it in the code base. That is, of course, completely untrue. Now then, I'm not saying that something as central as the topic at hand has a zero maintenance cost associated with it, especially if it's constantly being run into by the developers, but I do see it used WAY to often here for it to be applicable in every case. From what I can tell, in many cases, when one developer on the list doesn't want to maintain or sees little value in a feature, it suddenly seems to have a high price associated with it. We need to be sure we're making the distinction between, I don't care to maintain this, and, maintaining this code is prohibitively high given it's feature return...because In other words, I find this argument used often here will little to nothing used in context which would quantify it. Worse yet, it generally goes unchallenged and unquestioned. I'm afraid that we have already dropped too much. For example we dropped time travel, but recent versions of Oracle now have some form of it, usable mostly for recovering accidentally deleted (and committed rows), although it is much harder to implement it using logs than using MVCC. I must admit, I never understood this myself but I'm sure I'm ignorant of the details. That's a straw man argument. Actually it was meant to be 'one straw man against another straw man argument' ;) Was clear to me! I thought you made the point rather well. What we (or I, anyway) are arguing is that the relational model does everything that table inheritance does, and at least as easily. The problem is that 'the relational model' does nothing by itself. It is always the developers/DBAs who have to do things. And at least for some brain shapes it is much more convenient to inherit tables than to (re)factor stuff into several tables to simulate inheritance using the relational model. Agreed. It's important to remember, there are some cases where the conceptual implications can allow for more freedom in implementation. This is the point that was being made with the pure C comment. Sure, I can do pretty much anything in asm, but that approach doesn't suddenly invalidate every other way/language/concept/idiom to trying to accomplish as given task. Simply put, much of the power you get from any tool is often the flexibility of a given tool to address a problem domain in many different ways rather than just one. Just because it doesn't fit your paradigm doesn't mean it doesn't fit nicely into someone else's. I still think that inheritance should be enchanced and made compatible with standards not removed. I completely agree with that! Extending the model adds complexity without adding the ability to do things you couldn't easily do before. (This, IMHO, makes table inheritance quite inelegant.) Then explain why SQL99 has included inheritance ? Yes please. I'm very interested in hearing a rebuttal to this one. Greg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Greg Copeland [EMAIL PROTECTED] writes: I seem to find this argument a lot on the list here. For some reason, many of the developers are under the impression that even if code is never touched, it has a very high level of effort to keep it in the code base. That is, of course, completely untrue. FWIW, I did not notice any of the core developers making that case. As far as I'm concerned, any patch to remove inheritance will be rejected out of hand. It's not costing us anything significant to maintain as-is, and there are a goodly number of people using it. Extending it (eg, making cross-table indexes to support inherited uniqueness constraints) is a different kettle of fish --- but until someone steps up to the plate with an implementation proposal, it's rather futile to speculate what that might cost. In the meantime, the lack of any such plan is no argument for removing the functionality we do have. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On 31 Jul 2002, Hannu Krosing wrote: An it is often easier to map OO languages to OOR database when you dont have to change your mindset when going through the interface. But you have to anyway! Adding this inheritance does not remove the relational model; it's still there right in front of you, and you still have to use it. You have simply added another model to keep track of as well. And I've done a fair amount of OO lanugage - relational database interfacing, and the problems I've encountered are not helped by table inheritance. In fact, table inheritance has been irrelevant. But maybe I missed some problems. allows you to do everything that inheritance allows you to do, but also more. * And you can do anything and more that can be done in C++ in C. Ok, this is really starting to annoy me. Can we stop with this argument, since you *know* it is attacking a straw man? If you have difficulty with keys and joins, well, you really probably want to stop and fix that problem before you do more work on a relational database It is of course beneficial to make joins faster, but it is often easier to do for more specific cases, when the user has implicitly stated what kind of a join he means. No, my point is, you simply cannot do good work at all on a relational DB without understanding keys and joins. It does not matter whether table inheritance is present or not. Therefore everybody effectivly using a database is going to have enough knowledge to do this stuff without table inheritance. One example of that is the existance of contrib/intagg which is meant to make the relational method usable (performance-wise) for a class of problems where _pure_ relational way falls down. You seem to be confusing the relational model with a particular implementation of a relational database. The relational model handles this just fine, because the relational model doesn't have performance. This particular contrib module does not change anything at all about the relational model as implemented in postgres. It just provides a particular performance work-around. Note also that the performance problem can also be fixed in other ways; under MS-SQL server I'd simply use a clustered index on the one-to-many table. In fact, given that contrib/intagg works only with relatively static data, I'm not sure why you'd use it instead of just using the CLUSTER command once in a while. SQL has had pressure to be usable for a broad range of real-world problems from the beginning, which theory has not. SQL is actually much less usable for many real-world problems than a proper relational language is. But as I said, read Date, and then argue; I'm not going to spend days rewriting his books here. |Date and Darwen's _Foundation for Future Database Systems: the |Third Manifesto_ goes into much more detail about how they feel |object-oriented stuff should happen in relational databases. Appendix E |(Subtables and Supertables) discusses table inheritance. It ends with |this statement: | |To sum up: It looks as if the whole business of a subtable |inheriting columns from a supertable is nothing but a syntatic |shorthand--not that there is anything wrong with syntatic |shorthands in general, of course, but this particular shorthand |does not seem particularly useful, and in any case it is always |more than adequately supported by the conventional view mechanism. Which is clearly not true in PostgreSQL's case, as adequate support would IMHO mean that the rules for insert/update/delete were generated automatically for views as they are for select. It certainly would be nice if we did that. Of course we could go the other way and remove support for VIEW's as they can be done using a table and a ON SELECT DO INSTEAD rule. Actually this is how they are done. *Sigh*. You seem to be unable to distinguish between changes to the conceptual model of a system and changes to implementation details. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Mon, 2002-07-29 at 18:30, Bruce Momjian wrote: Curt Sampson wrote: I'm still waiting to find out just what advantage table inheritance offers. I've asked a couple of times here, and nobody has even started to come up with anything. We inherited inheritance from Berkeley. I doubt we would have added it ourselves. It causes too much complexity in other parts of the system. How about dropping it, then? Just start to emit WARNING: inheritance will be dropped with postgres 8.0 WARNING: please refer to http://.../ for an explanation why. right now on every CREATE TABLE that uses it. cheers -- vbi -- secure email with gpg http://fortytwo.ch/gpg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
[don't cc: me, please.] [please leave proper attribution in] On Tue, 2002-07-30 at 10:45, Christopher Kings-Lynne wrote: We inherited inheritance from Berkeley. I doubt we would have added it ourselves. It causes too much complexity in other parts of the system. [Inheritance] How about dropping it, then? [...] Why? It doesn't hurt you personally! That's correct. Plus, it would annoy a _boatload_ of existing inheritance users. Bruce Momjian: It causes too much complexity in other parts of the system. That's one reason. Curt Sampson wrote: I'm still waiting to find out just what advantage table inheritance offers. I've asked a couple of times here, and nobody has even started to come up with anything. and there is nothing whatsoever that table inheritance does that the relational model does not handle That's the other one. cheers -- vbi -- secure email with gpg http://fortytwo.ch/gpg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
[No cc: please. Especially if you're not commenting on anything I said] On Tue, 2002-07-30 at 13:46, D'Arcy J.M. Cain wrote: Curt Sampson wrote: I'm still waiting to find out just what advantage table inheritance offers. I've asked a couple of times here, and nobody has even started to come up with anything. I think one of the values of it is that it is something that no one else has. It distinguishes us. Col. Let's have the 'automatically phone KFC if developer works more than 8 hours non-stop' feature, *that* is something nobody else has. Yes. Cool. In other words: this is an absolutely bogus argument. As an implementor I'm always wary of using features nobody else has, especially in databases. So, if I'd want postgres to have one thing nobody else has, it would be the most complete standard SQL implementation - so it would at least be the other products' fault if I'd have to do any special porting work to/from postgres. cheers -- vbi -- secure email with gpg http://fortytwo.ch/gpg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
As an implementor I'm always wary of using features nobody else has, especially in databases. So, if I'd want postgres to have one thing nobody else has, it would be the most complete standard SQL implementation - so it would at least be the other products' fault if I'd have to do any special porting work to/from postgres. Why can't both be done? If nobody extended the spec or came up with new features there wouldn't exactly be any progress. Yes, meeting the spec is a good goal, and one that is getting quite close as far as the SQL part goes -- but it shouldn't be the only goal. Inheritance currently saves me from issuing ~4 inserts, updates, deletes as it handles it itself. If indexes and a couple other things worked across the entire tree it could be more useful. I think what we need to do is expand on it, not blow it away. There is a list of spec features we support. Stick to those (or the subset) that is appropriate for portability. If you plan on making an embedded DB Based application the extra features may be useful. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
[Still no cc:s please] On Tue, 2002-07-30 at 14:28, D'Arcy J.M. Cain wrote: * Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] [020730 08:01]: On Tue, 2002-07-30 at 13:46, D'Arcy J.M. Cain wrote: I think one of the values of it is that it is something that no one else has. It distinguishes us. Col. Let's have the 'automatically phone KFC if developer works more than 8 hours non-stop' feature, *that* is something nobody else has. Yes. Cool. Excuse me all to hell but are you in the junior debating class or what? Sure, I was taking it to the extreme here (And I really am sorry if you felt offended by my remark). But I strongly feel that having a feature because 'it is something that no one else has. It distinguishes us.' is no justification at all. Of course, if a feature provides some real use, then it is worth having (yes, even if it's not in the standard). But exactly this seems not so clear in the case of inheritance in postgres. (And that's where I'm starting to say things I've said before. So I'll just shut up now.) cheers -- vbi -- secure email with gpg http://fortytwo.ch/gpg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Adrian 'Dagurashibanipal' von Bidder wrote: (And that's where I'm starting to say things I've said before. So I'll just shut up now.) May be you can contribute some code :) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
2. I expect that even most PostgreSQL--or even database--experts don't have a real understanding of relational theory, anyway. That we still have table inheritance shows that. As far as I can tell, there is nothing whatsoever that table inheritance does that the relational model does not handle; the whole OO thing is just another, redundant way of doing what we already ought to be able to do within the relational model. I'm still waiting to find out just what advantage table inheritance offers. I've asked a couple of times here, and nobody has even started to come up with anything. Can you point me (someone without a real understanding of relational theory) to some good resources that explain the concepts well? Regards, Jeff ---(end of broadcast)--- TIP 3: 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: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Adrian 'Dagurashibanipal' von Bidder wrote: Checking application/pgp-signature: FAILURE -- Start of PGP signed section. [Still no cc:s please] On Tue, 2002-07-30 at 14:28, D'Arcy J.M. Cain wrote: * Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] [020730 08:01]: On Tue, 2002-07-30 at 13:46, D'Arcy J.M. Cain wrote: I think one of the values of it is that it is something that no one else has. It distinguishes us. Col. Let's have the 'automatically phone KFC if developer works more than 8 hours non-stop' feature, *that* is something nobody else has. Yes. Cool. Excuse me all to hell but are you in the junior debating class or what? Sure, I was taking it to the extreme here (And I really am sorry if you felt offended by my remark). But I strongly feel that having a feature because 'it is something that no one else has. It distinguishes us.' is no justification at all. I thought the KFC thing was very funny. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Tue, 30 Jul 2002, Jeff Davis wrote: Can you point me (someone without a real understanding of relational theory) to some good resources that explain the concepts well? C. J. Date's _An Introduction to Database Systems, Seventh Edition_ is a fat tome that will give you an extremely good grasp of relational theory if you take the time to study it. Even just browsing it is well worthwhile. It has some discussion of object-oriented database systems as well. In particular (you'll see the relevance of this below) it has an excellent analysis of the updatability of views. Date and Darwen's _Foundation for Future Database Systems: the Third Manifesto_ goes into much more detail about how they feel object-oriented stuff should happen in relational databases. Appendix E (Subtables and Supertables) discusses table inheritance. It ends with this statement: To sum up: It looks as if the whole business of a subtable inheriting columns from a supertable is nothing but a syntatic shorthand--not that there is anything wrong with syntatic shorthands in general, of course, but this particular shorthand does not seem particularly useful, and in any case it is always more than adequately supported by the conventional view mechanism. (This, BTW, addresses the note someone else made here about the subtable/supertable thing letting him do one insert instead of two or three; he just needs to create a view and appropriate rules, and he'll get exactly the same effect. And maybe that will help fix his index problems, too) cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
We inherited inheritance from Berkeley. I doubt we would have added it ourselves. It causes too much complexity in other parts of the system. How about dropping it, then? Just start to emit WARNING: inheritance will be dropped with postgres 8.0 WARNING: please refer to http://.../ for an explanation why. right now on every CREATE TABLE that uses it. Why? It doesn't hurt you personally! Plus, it would annoy a _boatload_ of existing inheritance users. A more interesting question I think is how to allow our indexes to span multiple relations, _without_ causing any performance degradation for non inheritance users... Chris ---(end of broadcast)--- TIP 3: 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: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Tue, 2002-07-30 at 14:51, Adrian 'Dagurashibanipal' von Bidder wrote: Bruce Momjian: It causes too much complexity in other parts of the system. That's one reason. Seems like somewhat valid reason. But still not enough to do a lot of work _and_ annoy a lot of existing users :) Curt Sampson wrote: I'm still waiting to find out just what advantage table inheritance offers. I've asked a couple of times here, and nobody has even started to come up with anything. and there is nothing whatsoever that table inheritance does that the relational model does not handle That's the other one. That's quite bogus imho. You could just as well argue that there is nothing that relational model handles that can't be done in pure C. Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
* Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] [020730 04:20]:
On Mon, 2002-07-29 at 18:30, Bruce Momjian wrote:
Curt Sampson wrote:
I'm still waiting to find out just what advantage table inheritance
offers. I've asked a couple of times here, and nobody has even started
to come up with anything.
I think one of the values of it is that it is something that no one else
has. It distinguishes us.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Inheritance (was: Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?)
I'm still waiting to find out just what advantage table inheritance offers. I've asked a couple of times here, and nobody has even started to come up with anything. and there is nothing whatsoever that table inheritance does that the relational model does not handle That's the other one. Irrelevant - thousands of people are using the feature! Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Tue, Jul 30, 2002 at 02:01:35PM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: As an implementor I'm always wary of using features nobody else has, especially in databases. So, if I'd want postgres to have one thing nobody else has, it would be the most complete standard SQL implementation - so it would at least be the other products' fault if I'd have to do any special porting work to/from postgres. SQL99 includes inheritance (albeit a somewhat different implementation than the design in Postgres right now) -- so the most complete standard SQL implementation would need to include inheritance. I'd say removing inheritence would be a waste of time -- it would probably be easier to just fix its deficiencies. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
... But I strongly feel that having a feature because 'it is something that no one else has. It distinguishes us.' is no justification at all. One reason why we have a database which *does* come very close to the standards is precisely because it had (and has) things which no one else had (or has). It demonstrated how to do things which are now part of SQL99, but which were not implemented *anywhere else* back in the early '90s. Inheritance is not as well supported by us, but that is our fault for focusing on other things recently. I think that some of the recent work will end up benefiting inheritance features, so these might make some progress soon too. Search and destroy missions to eliminate all that is not standard will diminish the product, because we will be constrained to work entirely within the boundaries of a standard which is poorly thought out around the edges. If our boundaries are always just a bit wider than that we'll be OK ;) All imho of course... - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On 29 Jul 2002, Hannu Krosing wrote: Curt Sampson wrote: I'm still waiting to find out just what advantage table inheritance offers. I've asked a couple of times here, and nobody has even started to come up with anything. It is mostly a syntactic thing that makes it easier to humans to write cleaner code. And how is using table inheritance cleaner than doing it the relational way? It adds extra complexity to the system, which is automatically a reduction in cleanliness, so it would have to have some correspondingly cleanliness-increasing advantages in order to be cleaner, overall. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On 30 Jul 2002, Hannu Krosing wrote: On Tue, 2002-07-30 at 14:51, Adrian 'Dagurashibanipal' von Bidder wrote: Bruce Momjian: It causes too much complexity in other parts of the system. That's one reason. Seems like somewhat valid reason. But still not enough to do a lot of work _and_ annoy a lot of existing users :) It's almost unquestionably more work to maintain than to drop. Dropping support for it is a one-time operation. Maintaining it is an ongoing expense. That's quite bogus imho. You could just as well argue that there is nothing that relational model handles that can't be done in pure C. That's a straw man argument. What we (or I, anyway) are arguing is that the relational model does everything that table inheritance does, and at least as easily. Extending the model adds complexity without adding the ability to do things you couldn't easily do before. (This, IMHO, makes table inheritance quite inelegant.) cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
As for why PostgreSQL is less popular than MySQL, I think it is all momentum from 1996 when MySQL worked and we sometimes crashed. Looking forward, I don't know many people who choose MySQL _if_ they consider both PostgreSQL and MySQL, so the discussions people have over MySQL vs. PostgreSQL are valuable because they get people to consider MySQL alternatives, and once they do, they usually choose PostgreSQL. As for momentum, we still have a smaller userbase than MySQL, but we are increasing our userbase at a fast rate, perhaps faster than MySQL at this point. I think the fact that the PHP guys _pride_ themselves on having built-in MySQL support is another huge reason. They look at it is an example of what can be achieved with integration. The FreeBSD PHP port, as another example, has 'MySQL support' ticked by default. Not quite so much work is put into PHP's PostgreSQL support as MySQL's, so it's often buggy (tell me about it). Also, the utter lack of knowledge about relational theory and SQL is a factor in both newbies and self-taught developers. For instance, in the last few days I have answered questions like these on PHP Builder: I use SELECT * FROM table WHERE a = 3. How do I get all rows? Can I put a = ALL or something? Why don't my javascript variables work in my SQL statements? I have two tables and a referencing ID, and I keep getting rows in my child table that don't match a row in the parent table, what is a query that I can run regularly to remove these problem rows? ...and so on... Why would someone asking the above questions use anything other than the 'default' PHP database? Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Tue, 2002-07-30 at 16:00, Curt Sampson wrote: On 30 Jul 2002, Hannu Krosing wrote: On Tue, 2002-07-30 at 14:51, Adrian 'Dagurashibanipal' von Bidder wrote: Bruce Momjian: It causes too much complexity in other parts of the system. That's one reason. Seems like somewhat valid reason. But still not enough to do a lot of work _and_ annoy a lot of existing users :) It's almost unquestionably more work to maintain than to drop. Dropping support for it is a one-time operation. Maintaining it is an ongoing expense. I would not rush to drop advanced features, as they may be hard to put back later. If they stay in, even in broken form, then there wont be nearly as much patches which make fixing them harder. I'm afraid that we have already dropped too much. For example we dropped time travel, but recent versions of Oracle now have some form of it, usable mostly for recovering accidentally deleted (and committed rows), although it is much harder to implement it using logs than using MVCC. Also, I suspect that dropping support for multiple return sets for one query was done too fast. That's quite bogus imho. You could just as well argue that there is nothing that relational model handles that can't be done in pure C. That's a straw man argument. Actually it was meant to be 'one straw man against another straw man argument' ;) What we (or I, anyway) are arguing is that the relational model does everything that table inheritance does, and at least as easily. The problem is that 'the relational model' does nothing by itself. It is always the developers/DBAs who have to do things. And at least for some brain shapes it is much more convenient to inherit tables than to (re)factor stuff into several tables to simulate inheritance using the relational model. I still think that inheritance should be enchanced and made compatible with standards not removed. Extending the model adds complexity without adding the ability to do things you couldn't easily do before. (This, IMHO, makes table inheritance quite inelegant.) Then explain why SQL99 has included inheritance ? --- Hannu ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On 31 Jul 2002, Hannu Krosing wrote: I would not rush to drop advanced features, as they may be hard to put back later. If they are hard to put back, it's generally because the other code in the system that relates to it has changed, so you can't just bring back what is in the old versions in the CVS repository. But if the code was left in, that meant that someone had to make all of those integration changes you'd have to make to bring the code back; it's just they had to make it as they were adding new features and whatnot. If in the end you decide that the feature you didn't drop isn't important, you just did a lot of work for nothing. You may also slow down or stop the implementation of other, more useful features, because people find that the work to add them isn't worthwhile, due to having to change too much code. If they stay in, even in broken form, then there wont be nearly as much patches which make fixing them harder. Summary: someone always has to do the patches. It's just a question of whether you *might* do them *if* you decide to bring the feature back, or whether you *will* do them because the feature is there. What we (or I, anyway) are arguing is that the relational model does everything that table inheritance does, and at least as easily. The problem is that 'the relational model' does nothing by itself. It is always the developers/DBAs who have to do things. Ok. So the developer can do what table inheritance does just as easily in the relational model. And at least for some brain shapes it is much more convenient to inherit tables than to (re)factor stuff into several tables to simulate inheritance using the relational model. I highly doubt that. Relating two tables to each other via a key, and joining them together, allows you to do everything that inheritance allows you to do, but also more. If you have difficulty with keys and joins, well, you really probably want to stop and fix that problem before you do more work on a relational database Extending the model adds complexity without adding the ability to do things you couldn't easily do before. (This, IMHO, makes table inheritance quite inelegant.) Then explain why SQL99 has included inheritance ? Becuase SQL has a long, long history of doing things badly. The language has been non-relational in many ways from the very beginning. But Codd and Date argue that much better than I do, so I'd prefer you read their books and respond to those arguments. I can provide references if you need them. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Mon, 2002-07-29 at 08:53, [EMAIL PROTECTED] wrote: Just a long standing curiosity? e) Inertia. MySQL got more popular way back when; the reasons may no longer f) Win32 Support. I can download a setup.exe for mysql and have it up and running quickly on Windows. I think that native Win32 support will go a long way toward making Postgres more popular ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
I highly doubt that. Relating two tables to each other via a key, and joining them together, allows you to do everything that inheritance allows you to do, but also more. If you have difficulty with keys and joins, well, you really probably want to stop and fix that problem before you do more work on a relational database I'm still not convinced of this. For example, my friend has a hardware e-store and every different class of hardware has different properties. ie modems have baud and network cards have speed and video cards have ram. He simply just has a 'products' table from which he extends 'networkcard_products', etc. with the additional fields. Easy. Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Mon, 2002-07-29 at 08:53, [EMAIL PROTECTED] wrote: Just a long standing curiosity? e) Inertia. MySQL got more popular way back when; the reasons may no longer f) Win32 Support. I can download a setup.exe for mysql and have it up and running quickly on Windows. I think that native Win32 support will go a long way toward making Postgres more popular Speaking of that - wasn't someone going to branch the CVS with a whole lot of Win32 support stuff? Jan? Chris ---(end of broadcast)--- TIP 3: 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: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Wed, 31 Jul 2002, Christopher Kings-Lynne wrote: I highly doubt that. Relating two tables to each other via a key, and joining them together, allows you to do everything that inheritance allows you to do, but also more. If you have difficulty with keys and joins, well, you really probably want to stop and fix that problem before you do more work on a relational database I'm still not convinced of this. For example, my friend has a hardware e-store and every different class of hardware has different properties. ie modems have baud and network cards have speed and video cards have ram. He simply just has a 'products' table from which he extends 'networkcard_products', etc. with the additional fields. Easy. And what's the problem with networkcard_products being a separate table that shares a key with the products table? CREATE TABLE products (product_id int, ...) CREATE TABLE networkcard_products_data (product_id int, ...) CREATE VIEW networkcard_products AS SELECT products.product_id, ... FROM products JOINT networkcard_products_data USING (product_id) What functionality does table inheritance offer that this traditional relational method of doing things doesn't? cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Curt Sampson wrote: On Wed, 31 Jul 2002, Christopher Kings-Lynne wrote: I highly doubt that. Relating two tables to each other via a key, and joining them together, allows you to do everything that inheritance allows you to do, but also more. If you have difficulty with keys and joins, well, you really probably want to stop and fix that problem before you do more work on a relational database I'm still not convinced of this. For example, my friend has a hardware e-store and every different class of hardware has different properties. ie modems have baud and network cards have speed and video cards have ram. He simply just has a 'products' table from which he extends 'networkcard_products', etc. with the additional fields. Easy. And what's the problem with networkcard_products being a separate table that shares a key with the products table? CREATE TABLE products (product_id int, ...) CREATE TABLE networkcard_products_data (product_id int, ...) CREATE VIEW networkcard_products AS SELECT products.product_id, ... FROM products JOINT networkcard_products_data USING (product_id) What functionality does table inheritance offer that this traditional relational method of doing things doesn't? You can add children without modifying your code. It is classic C++ inheritance; parent table accesses work with the new child tables automatically. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Tue, 30 Jul 2002, Bruce Momjian wrote: You can add children without modifying your code. It is classic C++ inheritance; parent table accesses work with the new child tables automatically. I don't see how my method doesn't do this as well. What code do you have to modify in the relational way of doing things that you don't in this inheritance way? cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Curt Sampson wrote: On Tue, 30 Jul 2002, Bruce Momjian wrote: You can add children without modifying your code. It is classic C++ inheritance; parent table accesses work with the new child tables automatically. I don't see how my method doesn't do this as well. What code do you have to modify in the relational way of doing things that you don't in this inheritance way? Seems like you have to modify your views to handle this, at least in the example you just posted, right? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: 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: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Tue, 30 Jul 2002, Bruce Momjian wrote: Curt Sampson wrote: On Tue, 30 Jul 2002, Bruce Momjian wrote: You can add children without modifying your code. It is classic C++ inheritance; parent table accesses work with the new child tables automatically. I don't see how my method doesn't do this as well. What code do you have to modify in the relational way of doing things that you don't in this inheritance way? Seems like you have to modify your views to handle this, at least in the example you just posted, right? You need to create a new view for the child table, yeah. But you had to create a child table anyway. But all the previously existing code you had continues to work unchanged. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 3: 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: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Wed, 2002-07-31 at 04:35, Curt Sampson wrote: On 31 Jul 2002, Hannu Krosing wrote: I would not rush to drop advanced features, as they may be hard to put back later. If they are hard to put back, it's generally because the other code in the system that relates to it has changed, so you can't just bring back what is in the old versions in the CVS repository. But if the code was left in, that meant that someone had to make all of those integration changes you'd have to make to bring the code back; it's just they had to make it as they were adding new features and whatnot. If in the end you decide that the feature you didn't drop isn't important, you just did a lot of work for nothing. You may also slow down or stop the implementation of other, more useful features, because people find that the work to add them isn't worthwhile, due to having to change too much code. If they stay in, even in broken form, then there wont be nearly as much patches which make fixing them harder. Summary: someone always has to do the patches. It's just a question of whether you *might* do them *if* you decide to bring the feature back, or whether you *will* do them because the feature is there. Often there are more than one way to do things. And the feature being there may prompt the implementor to choose in favor of a way which does not rule out the feature. It does not neccessarily make that harder for new features, though it may. What we (or I, anyway) are arguing is that the relational model does everything that table inheritance does, and at least as easily. The problem is that 'the relational model' does nothing by itself. It is always the developers/DBAs who have to do things. Ok. So the developer can do what table inheritance does just as easily in the relational model. And at least for some brain shapes it is much more convenient to inherit tables than to (re)factor stuff into several tables to simulate inheritance using the relational model. I highly doubt that. I said it is personal ;) Some other brain shapes are more fit to working in relational model, even when writing front-ends in C++ or java. Relating two tables to each other via a key, and joining them together, It gets more complicated fast when inheritance hierarchies get deeper, and some info is often lost (or at least not explicitly visible from schema). That's why advanced modeling tools allow you to model things as inheritance hierarchies even when they have to map it to relational model for databases which do not support inheritance. An it is often easier to map OO languages to OOR database when you dont have to change your mindset when going through the interface. allows you to do everything that inheritance allows you to do, but also more. * you can do anything (and more ;) that DOMAINs do without domains. * And you can do anything and more that can be done in C++ in C. * And you can do anything sequences do and more without explicit syntax for sequences (except making them live outside of transactions, but this is mainly a performance hack and sequences are outside of relational theory anyway ;) * And as I already mentioned, you can compute anything on a Turing Machine (I doubt you can compute more, but it is not entirely impossible as it has to work 'more' ;) If you have difficulty with keys and joins, well, you really probably want to stop and fix that problem before you do more work on a relational database It is of course beneficial to make joins faster, but it is often easier to do for more specific cases, when the user has implicitly stated what kind of a join he means. One example of that is the existance of contrib/intagg which is meant to make the relational method usable (performance-wise) for a class of problems where _pure_ relational way falls down. Extending the model adds complexity without adding the ability to do things you couldn't easily do before. (This, IMHO, makes table inheritance quite inelegant.) Then explain why SQL99 has included inheritance ? Becuase SQL has a long, long history of doing things badly. Or to rephrase it: SQL has a long, long history of doing things (though badly) The language has been non-relational in many ways from the very beginning. SQL has had pressure to be usable for a broad range of real-world problems from the beginning, which theory has not. But Codd and Date argue that much better than I do, so I'd prefer you read their books and respond to those arguments. I can provide references if you need them. In theory theory and practice are the same, in practice they are often not nearly so. From your reference: |Date and Darwen's _Foundation for Future Database Systems: the |Third Manifesto_ goes into much more detail about how they feel |object-oriented stuff should happen in relational databases. Appendix E |(Subtables and Supertables) discusses table inheritance. It ends with
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Hannu Krosing [EMAIL PROTECTED] writes: Of course we could go the other way and remove support for VIEW's as they can be done using a table and a ON SELECT DO INSTEAD rule. Two points for Hannu ;-) Seriously, this entire thread seems a waste of bandwidth to me. Inheritance as a feature isn't costing us anything very noticeable to maintain, and so I see no credible argument for expending the effort to rip it out --- even if I placed zero value on the annoyance factor for users who are depending on it. (Which I surely don't.) It's true that upgrading inheritance to handle features like cross-table uniqueness constraints or cross-table foreign keys is not trivial. But I don't know of any way to handle those problems in bog-standard SQL92 either. The fact that we don't have a solution to those issues at present doesn't strike me as a reason to rip out the functionality we do have. In short: give it a rest. There's lots of things we could be more productively arguing about. Think about which type conversions should be implicit, if you need a topic ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Why is MySQL more chosen over PostgreSQL?
Just a long standing curiosity? For most web sites MySQL seems to work fine, but overall PostgreSQL offers more capabilites so why build upon a limited base such as MySQL? Does anyone here have any idea as to why so many people select MySQL when both systems are open sourced? Matthew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Just a long standing curiosity? For most web sites MySQL seems to work fine, but overall PostgreSQL offers more capabilites so why build upon a limited base such as MySQL? Does anyone here have any idea as to why so many people select MySQL when both systems are open sourced? Three likely effects: a) ISP management toolsets include management tools for MySQL, and not PostgreSQL. (CPanel is an example of such a toolset.) b) Apparently the permissions model for PostgreSQL used to discourage its use in shared hosting environments. (Ask Neil Conway more about this.) c) There was corporate sponsorship of MySQL, and they probably spent money marketing it in the ISP web hosting market. d) MySQL is GPL-licensed, and some people consider that very important. (And are too stupid to grasp that they like XFree86, which _isn't_ licensed under the GPL... Of course, this is d), and I said three likely effects...) e) Inertia. MySQL got more popular way back when; the reasons may no longer apply, but nobody is going to move to PostgreSQL without _compelling_ reason, and you'll have to show something _really compelling_. -- (concatenate 'string cbbrowne @acm.org) http://cbbrowne.com/info/advocacy.html FLORIDA: Where your vote counts and counts and counts. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Mon, 29 Jul 2002 [EMAIL PROTECTED] wrote: [snip] e) Inertia. MySQL got more popular way back when; the reasons may no longer apply, but nobody is going to move to PostgreSQL without _compelling_ reason, and you'll have to show something _really compelling_. I would like to add one other thought. There are many web site designers that get thrust into being a web site programmer. Without an understanding of database design and a novice programmers (?) view of the process the benefits of letting the database (RDBMS) do the database work isn't recognized. They code it all in the CGI. Rod -- Open Source Software - Sometimes you get more than you paid for... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
well that and people tend to drift towards an easy answer, like php... amazing how that combo is so popular... hrrmm... Roderick A. Anderson writes: On Mon, 29 Jul 2002 [EMAIL PROTECTED] wrote: [snip] e) Inertia. MySQL got more popular way back when; the reasons may no longer apply, but nobody is going to move to PostgreSQL without _compelling_ reason, and you'll have to show something _really compelling_. I would like to add one other thought. There are many web site designers that get thrust into being a web site programmer. Without an understanding of database design and a novice programmers (?) view of the process the benefits of letting the database (RDBMS) do the database work isn't recognized. They code it all in the CGI. Rod -- Open Source Software - Sometimes you get more than you paid for... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Chris Humphries Development InfoStructure 540.366.9809 ---(end of broadcast)--- TIP 3: 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: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Mon, 29 Jul 2002, Chris Humphries wrote: well that and people tend to drift towards an easy answer, like php... amazing how that combo is so popular... hrrmm... Well people seem to get so ... about php that I didn't want to touch that topic. Rod -- Open Source Software - Sometimes you get more than you paid for... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Mon, 29 Jul 2002, Roderick A. Anderson wrote: I would like to add one other thought. There are many web site designers that get thrust into being a web site programmer. Without an understanding of database design and a novice programmers (?) view of the process the benefits of letting the database (RDBMS) do the database work isn't recognized. They code it all in the CGI. Well, I'll add two points to this, then: 1. Often there's a lot more benefit to moving the work from the database to the application structure. Database schemas are hard to change, and hard to keep under revision control. When I was doing a large website, it was much, much easier to say everything goes through these Java classes than everything goes through the database. I could change the database schema at will and know that my data was safe, because I could have old interfaces running simultaneously with new. (Though I'll admit, good view support would have mitigated this problem quite a lot. But there is *no* database in the world that has really good view support; they all fail on various updates where one can theoretically do the Right Thing, but in practice it's very difficult. And I don't think that's going to change any time soon.) 2. I expect that even most PostgreSQL--or even database--experts don't have a real understanding of relational theory, anyway. That we still have table inheritance shows that. As far as I can tell, there is nothing whatsoever that table inheritance does that the relational model does not handle; the whole OO thing is just another, redundant way of doing what we already ought to be able to do within the relational model. I'm still waiting to find out just what advantage table inheritance offers. I've asked a couple of times here, and nobody has even started to come up with anything. All that said, though, don't take this as any kind of a dismissal of postgres. It's in most ways better than MySQL and also some commericial systems, and many of its failures are being addressed. Postgres for some reason seems to attract some really, really smart people to work on it. If I could see something better, I'd be there. But I don't. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Curt Sampson wrote: I'm still waiting to find out just what advantage table inheritance offers. I've asked a couple of times here, and nobody has even started to come up with anything. We inherited inheritance from Berkeley. I doubt we would have added it ourselves. It causes too much complexity in other parts of the system. All that said, though, don't take this as any kind of a dismissal of postgres. It's in most ways better than MySQL and also some commericial systems, and many of its failures are being addressed. Postgres for some reason seems to attract some really, really smart people to work on it. If I could see something better, I'd be there. But I don't. Interbase/Firebird maybe? They just came out with a 1.0 release in March. As for why PostgreSQL is less popular than MySQL, I think it is all momentum from 1996 when MySQL worked and we sometimes crashed. Looking forward, I don't know many people who choose MySQL _if_ they consider both PostgreSQL and MySQL, so the discussions people have over MySQL vs. PostgreSQL are valuable because they get people to consider MySQL alternatives, and once they do, they usually choose PostgreSQL. As for momentum, we still have a smaller userbase than MySQL, but we are increasing our userbase at a fast rate, perhaps faster than MySQL at this point. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
Bruce Momjian wrote: Curt Sampson wrote: I'm still waiting to find out just what advantage table inheritance offers. I've asked a couple of times here, and nobody has even started to come up with anything. We inherited inheritance from Berkeley. I doubt we would have added it ourselves. It causes too much complexity in other parts of the system. ... As for why PostgreSQL is less popular than MySQL, I think it is all momentum from 1996 when MySQL worked and we sometimes crashed. Looking forward, I don't know many people who choose MySQL _if_ they consider both PostgreSQL and MySQL, so the discussions people have over MySQL vs. PostgreSQL are valuable because they get people to consider MySQL alternatives, and once they do, they usually choose PostgreSQL. As for momentum, we still have a smaller userbase than MySQL, but we are increasing our userbase at a fast rate, perhaps faster than MySQL at this point. Its all due to sort-order. If Oracle was open source MySQL would still be more popular. ;-) Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Mon, 29 Jul 2002, Bruce Momjian wrote: Curt Sampson wrote: I'm still waiting to find out just what advantage table inheritance offers. I've asked a couple of times here, and nobody has even started to come up with anything. We inherited inheritance from Berkeley. I doubt we would have added it ourselves. It causes too much complexity in other parts of the system. Ah, all the more reason to remove it, then! :-) But really, please don't take that as a criticism of the current development direction; I know it was inherited, and it's not new code. In fact, I think it probably wasn't until _The Third Manifsto_ came out in 1998 that it really became clear that table inheritance was not terribly useful--if it's even generally known now. And even so, I'm open to other opinions on that, since it's not been an intensive area of study by any means. All that said, though, don't take this as any kind of a dismissal of postgres. It's in most ways better than MySQL and also some commericial systems, and many of its failures are being addressed. Postgres for some reason seems to attract some really, really smart people to work on it. If I could see something better, I'd be there. But I don't. Interbase/Firebird maybe? They just came out with a 1.0 release in March. Once in a while I go back to it, but I still can't build the darn thing from scratch. Which makes it a bit difficult to evaluate As for why PostgreSQL is less popular than MySQL, I think it is all momentum from 1996 when MySQL worked and we sometimes crashed. Right. I have a lot of hope. After all, MySQL was for a couple of years a second-runner to mSQL, remember? cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 3: 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: [HACKERS] Why is MySQL more chosen over PostgreSQL?
On Mon, 2002-07-29 at 19:01, Curt Sampson wrote: On Mon, 29 Jul 2002, Bruce Momjian wrote: Curt Sampson wrote: I'm still waiting to find out just what advantage table inheritance offers. I've asked a couple of times here, and nobody has even started to come up with anything. It is mostly a syntactic thing that makes it easier to humans to write cleaner code. Otherwise, it is proved that anything can be written for a Turing Machine ;) We inherited inheritance from Berkeley. I doubt we would have added it ourselves. It causes too much complexity in other parts of the system. Ah, all the more reason to remove it, then! :-) It would make more sense to make it compatible with SQL99 and drop the current behaviour only after that if possible. As it stands now it is a strange mix of SQL99's CREATE TABLE thistable(...,LIKE anothertable,...); and CREATE table mytable(...) UNDER anothertable; with only a few additional goodies, like SELECT* (i.e not ONLY) which selects from all tables that inherit from this. other things that should be done are not (like inheriting constraints, foreign and primary keys, triggers, ...) Also we currently can't return more than one recordset from a query, which also makes selecting from an inheritance hierarchy less versatile. --- Hannu ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
