[GENERAL] Are there any projects interested in object functionality? (+ rule bases)
Dear all, for the sake academic teaching, a colleague asked me in how far PostgreSQL does support object functionality these days. I am afraid my web research was not very fruitful to him; the impression is that hardly anybody is occupied in working on PostgreSQL object functionality -- have ORM mappers grown so strong? The docs report that the SQL/OLB ISO/IEC 9075-10 part of the SQL standard have no implementation yet. So I'd like to place my questions here: * are there any people / projects known which are interested in ORDBMS / OODBMS usage of PostgreSQL? Strict SQL standard conformance is less important than the possibility to provide instructive and impressive examples to students. * are there any people / projects known which are interested in extending PostgreSQL at a higher level (plpgsql, creating operators, etc.) for the sake of ORDBMS / OODBMS functionality? * are there any people / projects known which are interested in extending PostgreSQL on the level of developing C code for the sake of ORDBMS / OODBMS functionality? * in how far does the backend support such efforts -- would it do fine, or is rather to be expected that doing ORDBMS / OODBMS driven queries would lead to disastrous performance? * are there any people / projects known which are interested in using the rule (?trigger?) system of PostgreSQL (maybe with extensions) to achieve some kind of rule base / datalog type inference engines? In how far does the backend constrain this in regard of performance? Thanks a lot in advance, Nick
Re: [GENERAL] Are there any projects interested in object functionality? (+ rule bases)
On 1/21/2011 2:16 AM, Nick Rudnick wrote: Dear all, for the sake academic teaching, a colleague asked me in how far PostgreSQL does support object functionality these days. I am afraid my web research was not very fruitful to him; the impression is that hardly anybody is occupied in working on PostgreSQL object functionality -- have ORM mappers grown so strong? The docs report that the SQL/OLB ISO/IEC 9075-10 part of the SQL standard have no implementation yet. Thanks a lot in advance, Nick Short answer: no. Here are some counter questions for you: Have you ever seen any actual real world usage of OORDBMS? Are there any products (good, useful products, not just academic playthings) that support OORDBMS? Bonus: If there is more than one product, do they share a common query language? You do realize that ORM sucks, right? Strict SQL standard conformance is less important than the possibility to provide instructive and impressive examples to students. Well! As long as its impressive! Who cares about anything else! I've seen the buzword OODBMS for as long as OOP, and while OOP came and went, OODBMS never amounted to anything. Let it go. If anything, OODBMS transformed into webservices. There is your common query language. JSON over HTTP! OOP in code is easily understandable. OOData? It doesnt even make sense. OOP in code means a container to hold your common data and code together. In PG you can use a Schema to do the same thing. OOP needs polymorphism. How does that even make sense with data? (Its a double rainbow) WHAT DOES IT EVEN MEAN?! Academia saw OOP revolutionize code, and I think they wanted something to revolutionize data as well. We have a set of rules and procedures for developing code... and those don't apply to data. (There is a tiny little gray area however, when you get to stored procedures, which is code, but dont let it fool you, its data). In fact, what if I told you: Code is just data. There, whew! I spent my existentialism for the month :-) -Andy -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Are there any projects interested in object functionality? (+ rule bases)
On Fri, 2011-01-21 at 09:10 -0600, Andy Colson wrote: On 1/21/2011 2:16 AM, Nick Rudnick wrote: Dear all, for the sake academic teaching, a colleague asked me in how far PostgreSQL does support object functionality these days. Although postgres at one time had ORDBMS as a goal, I haven't seen any real interest or work in that area for a long time. The OO features are primarily: 1. OIDs -- hidden columns with auto-generated number. At one time, OIDs were a part of every table, now they must be specified explicitly. They still remain on many of the system catalogs, but not all. Mostly, they are now just an implementation detail that people only notice when looking at the catalogs (and I am personally annoyed that they are hidden, because when looking at the catalogs usually you want to see the OIDs). 2. Inheritance This feature is now used almost exclusively for physical partitioning rather than logical design. You do realize that ORM sucks, right? Andy, please try to keep the criticism constructive. Nick, I think the problem with ORDBMS is that they essentially introduce pointers in the data, and that adds a lot of complexity. For instance, the relational algebra has nice closure properties. If you join two relations, you get another relation. But what if you introduce pointers? Well, then each table might start out with OIDs, but then when you join with another table and do a GROUP BY, you lose any meaningful OIDs. So what do you have? Something else. Therefore, you've lost closure. Now, maybe there is a good reason to sacrifice closure and other nice properties of the relational model. But there is a perception among many people (like Andy) that the case has not been made. Regards, Jeff Davis -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Are there any projects interested in object functionality? (+ rule bases)
2. Inheritance This feature is now used almost exclusively for physical partitioning rather than logical design. GNUmed uses it for logical design (albeit not OO) a lot. Karsten -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Are there any projects interested in object functionality? (+ rule bases)
On 01/21/2011 06:34 PM, Jeff Davis wrote: On Fri, 2011-01-21 at 09:10 -0600, Andy Colson wrote: You do realize that ORM sucks, right? Andy, please try to keep the criticism constructive. Sorry Nick. Didn't mean to be hostile. Thanks Jeff. -Andy -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Are there any projects interested in object functionality? (+ rule bases)
Hi Andy, to a considerable extent I agree with you -- but the motivation exactly is not typical business apps, but *academic teaching* needing a demonstration platform for *non-standard* apps -- these guys are a DB chair, and I was optimistic there might be some projects here which might allow them to use PostgreSQL for that sake. So I am meaning OO in a very broad sense. All the best, Nick On 01/21/2011 04:10 PM, Andy Colson wrote: Short answer: no. Here are some counter questions for you: Have you ever seen any actual real world usage of OORDBMS? Are there any products (good, useful products, not just academic playthings) that support OORDBMS? Bonus: If there is more than one product, do they share a common query language? You do realize that ORM sucks, right? Strict SQL standard conformance is less important than the possibility to provide instructive and impressive examples to students. Well! As long as its impressive! Who cares about anything else! I've seen the buzword OODBMS for as long as OOP, and while OOP came and went, OODBMS never amounted to anything. Let it go. If anything, OODBMS transformed into webservices. There is your common query language. JSON over HTTP! OOP in code is easily understandable. OOData? It doesnt even make sense. OOP in code means a container to hold your common data and code together. In PG you can use a Schema to do the same thing. OOP needs polymorphism. How does that even make sense with data? (Its a double rainbow) WHAT DOES IT EVEN MEAN?! Academia saw OOP revolutionize code, and I think they wanted something to revolutionize data as well. We have a set of rules and procedures for developing code... and those don't apply to data. (There is a tiny little gray area however, when you get to stored procedures, which is code, but dont let it fool you, its data). In fact, what if I told you: Code is just data. There, whew! I spent my existentialism for the month :-) -Andy -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Are there any projects interested in object functionality? (+ rule bases)
Hi Jeff, this is worse news than I expected -- I had that that at least somebody would be playing around with this... Of course there is a price to pay for OO functionality -- but is there evidence that, given I tweak the frontend into such a direction, PostreSQL due to its backend architecture will do really significantly slower than OODBMS/ORDBMS more specialized for that sake (the same with rules...)?? Or is it worth to give it a try? This would be my last resort, Nick Although postgres at one time had ORDBMS as a goal, I haven't seen any real interest or work in that area for a long time. The OO features are primarily: 1. OIDs -- hidden columns with auto-generated number. At one time, OIDs were a part of every table, ;-)) The time when I began using PostgreSQL... now they must be specified explicitly. They still remain on many of the system catalogs, but not all. Mostly, they are now just an implementation detail that people only notice when looking at the catalogs (and I am personally annoyed that they are hidden, because when looking at the catalogs usually you want to see the OIDs). 2. Inheritance This feature is now used almost exclusively for physical partitioning rather than logical design. Nick, I think the problem with ORDBMS is that they essentially introduce pointers in the data, and that adds a lot of complexity. For instance, the relational algebra has nice closure properties. If you join two relations, you get another relation. But what if you introduce pointers? Well, then each table might start out with OIDs, but then when you join with another table and do a GROUP BY, you lose any meaningful OIDs. So what do you have? Something else. Therefore, you've lost closure. Now, maybe there is a good reason to sacrifice closure and other nice properties of the relational model. But there is a perception among many people (like Andy) that the case has not been made. Regards, Jeff Davis -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
