Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Hi Josh, at first, thanks for all the interesting info given Correct, AFAIK. o extensions of PostgreSQL to support such a kind of usage have to be expected to be expected to be rejected from integration to the code base core -- i.e., if they are done, students have to be told «you can't expect this to become a part of PostgreSQL» Not necessarily. We rule out *very* few things from PostgreSQL; I think the TODO list only has 3 ideas which are contraindicated. After reading these points, I would say it really is a very liberal policy... and I can't resist the temptation to ask about garbage collection: I remember well PostgreSQL has an own garbage collection (palloc() etc.;I only know it is in utils of the backend, at mmgr), but I didn't find it on the TODO list; so o would you say hands off the garbage collection or could you imagine extensions? o would you consider the PostgreSQL garbage collection to be rather specific (e.g., DBMS specific optimizations) or heavily interwoven into the code -- or could it be conceivable that behaviour requirements from PostgreSQL could be specified so far that alternative garbage collections can be developed and inserted? However, the warning is that this particular *set* of ideas has some very high hurdles to jump before it could be considered seriously for core, and that none of the existing committers seem interested in helping with it. So the level of difficulty for the implementer would be considerably greater than for many other patches of less invasiveness and clearer apparent utility. Among the hurdles are: a. performance: you'd have to work out how to make nested object resolution not take forever and burn up the CPUs Time for a 'coming out': In the last years, I have mostly worked with pure typed declarative languages (Haskell, Mercury), so I personally have a type system like Hindley-Milner in mind, which by concept does not have infinite pointer chains and also in other regards seems to be in much closer relationship with relational database systems (an interesting, though early state effort: http://groups.inf.ed.ac.uk/links/). As (partially due to emerging multicore technology) the trend seems to go into this direction (Scala for Java, inclusion of FP functionality in C++), and such type system may be regarded as competitive with OO, I personally don't see much motivation for a such forced marriage like ISO/IEC 9075-10 (SQL/OLB). The difficulty in regard of pure typed declarative languages rather seems to be garbage collection (therefore the question above), as it in these language environments uses to be a very sophisticated piece of programming, subject of intensive research efforts, so it would be a problem if the PostgreSQL garbage collection would be equally complex. b. resolution: you'd need to come up with an object naming practice which compliments, intead of conflicts with, the SQL-standard syntax of course... c. utility: you'd have to demonstrate why all this was actually useful. in short gross words: a typed rulebase extension. ai. joint-venturing with leading teams in this area. Is this understood correctly, especially the last point, or did Robert/Tom just specifically address syntactical conflicts (between schema and object semantics) with the point notation? Syntactic conflicts are also significant, as anyone who's used EDB's packages mod can tell you. So these would need to be worked out as well, and NOT in a way which breaks backwards compatibility. completely d'accord... Otherwise, the striking lack of academical initiatives in the area of OO and rule inference on top of PostgreSQL appears to me as a demand to Hmmm. I don't know about that; I've never seen that academics *cared* whether or not their code god into -core. Unfortunately this is well said... Thanks for your infos, Nick -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
On Fri, Feb 11, 2011 at 6:40 PM, Nick Rudnick joerg.rudn...@t-online.de wrote: I remember well PostgreSQL has an own garbage collection (palloc() etc.;I only know it is in utils of the backend, at mmgr), but I didn't find it on the TODO list; so o would you say hands off the garbage collection or could you imagine extensions? o would you consider the PostgreSQL garbage collection to be rather specific (e.g., DBMS specific optimizations) or heavily interwoven into the code -- or could it be conceivable that behaviour requirements from PostgreSQL could be specified so far that alternative garbage collections can be developed and inserted? Despite occasional posturing, I think that our community tends to take a pretty pragmatic view of the world. If a patch can be shown to have more upside than downside, we tend to accept it. If it has more downside than upside, we reject it. Now, I think all of us have lists of things that we're most interested in working on, based on the problems that we encounter in real life. I worked on join removal because it solved particular problems that I ran into when building web applications. Greg Smith works on checkpointing and other issues related to disk I/O because he helps people build big honking servers that use PostgreSQL, and that's where he runs into problems. Kevin Grittner implemented SSI for true serializability because it solves a problem he has. If you're fired up about improving memory management, by all means have a crack at it. As an armchair quarterback, I'm a bit doubtful that there is a significant amount of efficiency or maintainability that can be squeezed out of that subsystem, but I'd be happy to be proven wrong. There are certainly workloads where palloc overhead is significant, and if someone can find a way to make a meaningful improvement there, we're not going to reject it because we didn't think of it ourselves. Time for a 'coming out': In the last years, I have mostly worked with pure typed declarative languages (Haskell, Mercury), so I personally have a type system like Hindley-Milner in mind, which by concept does not have infinite pointer chains and also in other regards seems to be in much closer relationship with relational database systems (an interesting, though early state effort: http://groups.inf.ed.ac.uk/links/). I've been interested in this in the past, but the implementation challenges are daunting. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
On Tue, Feb 8, 2011 at 2:23 AM, Nick Rudnick joerg.rudn...@t-online.de wrote: (my last two posts seemingly did not reach the HACKERS forum, so please let me resend the last one ;-) ) They got here - I think just no one had any further comment. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
On lör, 2011-02-05 at 12:26 +0100, Nick Rudnick wrote: o extensions of PostgreSQL to support such a kind of usage have to be expected to be expected to be rejected from integration to the code base core -- i.e., if they are done, students have to be told «you can't expect this to become a part of PostgreSQL» There are very varied interests in this community. But you have to keep in mind that PostgreSQL is a production software package, not a research platform. This doesn't mean that we discourage research with the PostgreSQL code base. But that should be done in a fork. Code aimed for inclusion in a proper PostgreSQL release should have demonstrable real life use and should be developed according to certain standards and in close corporation with the community. If a research project can deal with that, great, but typically, research projects are there to determine whether something could have real-life value in the first place, and development follows different standards of quality. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
o in the recent there are no efforts known to experiment with reference types, methods, or rule inference on top of PostgreSQL -- advice that can be given mostly points to the given documented functionality Correct, AFAIK. o extensions of PostgreSQL to support such a kind of usage have to be expected to be expected to be rejected from integration to the code base core -- i.e., if they are done, students have to be told «you can't expect this to become a part of PostgreSQL» Not necessarily. We rule out *very* few things from PostgreSQL; I think the TODO list only has 3 ideas which are contraindicated. However, the warning is that this particular *set* of ideas has some very high hurdles to jump before it could be considered seriously for core, and that none of the existing committers seem interested in helping with it. So the level of difficulty for the implementer would be considerably greater than for many other patches of less invasiveness and clearer apparent utility. Among the hurdles are: a. performance: you'd have to work out how to make nested object resolution not take forever and burn up the CPUs b. resolution: you'd need to come up with an object naming practice which compliments, intead of conflicts with, the SQL-standard syntax c. utility: you'd have to demonstrate why all this was actually useful. Is this understood correctly, especially the last point, or did Robert/Tom just specifically address syntactical conflicts (between schema and object semantics) with the point notation? Syntactic conflicts are also significant, as anyone who's used EDB's packages mod can tell you. So these would need to be worked out as well, and NOT in a way which breaks backwards compatibility. Otherwise, the striking lack of academical initiatives in the area of OO and rule inference on top of PostgreSQL appears to me as a demand to Hmmm. I don't know about that; I've never seen that academics *cared* whether or not their code god into -core. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
(my last two posts seemingly did not reach the HACKERS forum, so please let me resend the last one ;-) ) May I sum up? o in the recent there are no efforts known to experiment with reference types, methods, or rule inference on top of PostgreSQL -- advice that can be given mostly points to the given documented functionality o inside the PostgreSQL community, there is not many knowledge in circulation in regard of performance effects of using deeply nested data structures (with the possible exception of XML handling) or doing rule inference on top oof PostgreSQL -- but at least, there also are no substantial contraindications o extensions of PostgreSQL to support such a kind of usage have to be expected to be expected to be rejected from integration to the code base core -- i.e., if they are done, students have to be told «you can't expect this to become a part of PostgreSQL» Is this understood correctly, especially the last point, or did Robert/Tom just specifically address syntactical conflicts (between schema and object semantics) with the point notation? If not, it might be discouraging for lecture, as there might be interest to present something which at least might be imagined once to become a standard tool. Otherwise, the striking lack of academical initiatives in the area of OO and rule inference on top of PostgreSQL appears to me as a demand to a. check out academic sources, whether principle efficience issues of backend design discourage it so obviously that people do not even try it out b. if this is not the case, to propose this professor to try to fill the gap... ;-) In this case, regarding method semantics extensions, avoiding conflicts with existent language constructs certainly will be preferable, as these will be small projects. Cheers, Nick -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
May I sum up? o in the recent there are no efforts known to experiment with reference types, methods, or rule inference on top of PostgreSQL -- advice that can be given mostly points to the given documented functionality o inside the PostgreSQL community, there is not many knowledge in circulation in regard of performance effects of using deeply nested data structures (with the possible exception of XML handling) or doing rule inference on top oof PostgreSQL -- but at least, there also are no substantial contraindications o extensions of PostgreSQL to support such a kind of usage have to be expected to be expected to be rejected from integration to the code base core -- i.e., if they are done, students have to be told «you can't expect this to become a part of PostgreSQL» Is this understood correctly, especially the last point, or did Robert/Tom just specifically address syntactical conflicts (between schema and object semantics) with the point notation? If not, it might be discouraging for lecture, as there might be interest to present something which at least might be imagined once to become a standard tool. Otherwise, the striking lack of academical initiatives in the area of OO and rule inference on top of PostgreSQL appears to me as a demand to a. check out academic sources, whether principle efficience issues of backend design discourage it so obviously that people do not even try it out b. if this is not the case, to propose this professor to try to fill the gap... ;-) In this case, regarding method semantics extensions, avoiding conflicts with existent language constructs certainly will be preferable, as these will be small projects. Cheers, Nick -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
On Mon, Jan 31, 2011 at 9:53 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: It would help if you were a bit more specific. Do you mean you want to write something like foo.bar(baz) and have that mean call the bar method of foo and pass it baz as an argument? If so, that'd certainly be possible to implement for purposes of a college course, if you're so inclined - after all it's free software - but we'd probably not make such a change to core PG, because right now that would mean call the function bar in schema baz and pass it foo as an argument. We try not to break people's code to when adding nonstandard features. You would probably have better luck shoehorning in such a feature if the syntax looked like this: (foo).bar(baz) foo being a value of some type that has methods, and bar being a method name. Another possibility is foo-bar(baz) I agree with Robert's opinion that it'd be unlikely the project would accept such a patch into core, but if you're mainly interested in it for research purposes that needn't deter you. Using an arrow definitely seems less problematic than using a dot. Dot means too many things already. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
On Mon, Jan 31, 2011 at 11:41 PM, Pavel Stehule pavel.steh...@gmail.com wrote: CREATE METHOD next_color (n INT) RETURNS INT FOR colored_part_t RETURN SELF.color_id + n SELECT partno, color_id, DEREF(oid).next_color(1) AS next FROM colored_parts DEREF(oid)? That's just bizarre. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
2011/2/1 Robert Haas robertmh...@gmail.com: On Mon, Jan 31, 2011 at 9:53 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: It would help if you were a bit more specific. Do you mean you want to write something like foo.bar(baz) and have that mean call the bar method of foo and pass it baz as an argument? If so, that'd certainly be possible to implement for purposes of a college course, if you're so inclined - after all it's free software - but we'd probably not make such a change to core PG, because right now that would mean call the function bar in schema baz and pass it foo as an argument. We try not to break people's code to when adding nonstandard features. You would probably have better luck shoehorning in such a feature if the syntax looked like this: (foo).bar(baz) foo being a value of some type that has methods, and bar being a method name. Another possibility is foo-bar(baz) I agree with Robert's opinion that it'd be unlikely the project would accept such a patch into core, but if you're mainly interested in it for research purposes that needn't deter you. Using an arrow definitely seems less problematic than using a dot. Dot means too many things already. sure, but it's out of standard :( Pavel -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
2011/2/1 Robert Haas robertmh...@gmail.com: On Mon, Jan 31, 2011 at 11:41 PM, Pavel Stehule pavel.steh...@gmail.com wrote: CREATE METHOD next_color (n INT) RETURNS INT FOR colored_part_t RETURN SELF.color_id + n SELECT partno, color_id, DEREF(oid).next_color(1) AS next FROM colored_parts DEREF(oid)? That's just bizarre. have to look on this topic more complex :). There are some papers. It's sadly so these features wasn't used more and world is controlled by ORMs like Hibernate and company :( We did a some OOP meta language - PL/pgSQL translator and lot of tasks was processed simply without deep SQL programming. It was a strange tool :) - compiler to PL/pgSQL in PL/pgSQL :) Regards Pavel Stehule -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
On Tue, Feb 1, 2011 at 10:11 AM, Peter Eisentraut pete...@gmx.net wrote: The SQL standard has the method invocation clause that appears to allow: ...something.column.method(args) Good luck finding out how to interpret the dots, but it's specified somewhere. My head just exploded. It'd be kind of nice as a syntax and namespacing alternative, actually, but figuring out the compatibility problems would be a headache. No joke. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
On mån, 2011-01-31 at 21:53 -0500, Tom Lane wrote: You would probably have better luck shoehorning in such a feature if the syntax looked like this: (foo).bar(baz) foo being a value of some type that has methods, and bar being a method name. The SQL standard has the method invocation clause that appears to allow: ...something.column.method(args) Good luck finding out how to interpret the dots, but it's specified somewhere. It'd be kind of nice as a syntax and namespacing alternative, actually, but figuring out the compatibility problems would be a headache. Another possibility is foo-bar(baz) This is in the SQL standard under attribute or method reference, but it requires the left side to be of a reference type, which is something that we don't have. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
On 02/01/2011 03:36 AM, Robert Haas wrote:
On Mon, Jan 31, 2011 at 5:40 PM, Nick Rudnickjoerg.rudn...@t-online.de wrote:
* In this regard it is of interest in how far there are principal efficiency
problems with the support of (deeply nested) object like structure by the
backend, or if the backend may be expected to do this job not terribly worse
then more specialized OODMS -- of course, I would be interested in any
discussions of these topics...
I simply don't know what a more-specialized OODBMS would do that is
similar to or different than what PostgreSQL does, so it's hard to
comment. I don't immediately see why we'd be any less efficient, but
without knowing what algorithms are in use on the other side, it's a
bit hard to say.
I assume this is a questions for experts in DB optimization -- I am
afraid that the indices or the query optimization might be suboptimal
for deeply nested structures -- on the other hand, it might be possible
that somebody would say that, with some WHISKY indices (;-)) or the
like, PostgreSQL would do good. After all, PostgreSQL (and I guess the
backend, too) is a very modular piece of software...
* The same question for doing rule bases on top of the PostgreSQL backend...
I'm not sure if you're referring to the type of rules added by the SQL
command CREATE RULE here, or some other kind of rule. But the rules
added by CREATE RULE are generally not too useful. Most serious
server programming is done using triggers.
For the kind usage of I am interested in please look:
http://en.wikipedia.org/wiki/Expert_system
http://en.wikipedia.org/wiki/Inference_engine
http://en.wikipedia.org/wiki/Deductive_database
http://en.wikipedia.org/wiki/Datalog
http://en.wikipedia.org/wiki/Forward_chaining
And yes, this can be done -- here an inelegant example (with many
obvious todos), demonstrating the simple «Colonel West example» of
Artificial Intelligence, a Modern Approach by Russell/Norvig in plain
PostgreSQL RULEs (in attachment, too):
= 8 ==
-- for primordial facts:
CREATE TABLE american(person text);
CREATE TABLE missile(thing text);
CREATE TABLE owns(owner text, property text);
CREATE TABLE enemy(person text, target text);
-- for derived facts:
CREATE TABLE weapon(thing text);
CREATE TABLE sells(seller text, thing text, buyer text);
CREATE TABLE hostile(person text);
CREATE TABLE criminal(person text);
-- rules:
CREATE RULE missile_is_a_weapon AS
ON INSERT TO missile
DO ALSO
INSERT INTO weapon SELECT NEW.thing;
CREATE RULE enemy_of_america_is_hostile AS
ON INSERT TO enemy WHERE NEW.target = 'America'
DO ALSO
INSERT INTO hostile SELECT NEW.person;
-- nono_can_get_missiles_only_from_west
CREATE RULE nono_can_get_missiles_only_from_west__missile AS
ON INSERT TO missile
DO ALSO
INSERT INTO sells
SELECT 'West' AS seller, NEW.thing, 'Nono' AS buyer
FROM owns WHERE owner='Nono' AND property=NEW.thing;
CREATE RULE nono_can_get_missiles_only_from_west__owns AS
ON INSERT TO owns WHERE NEW.owner='Nono'
DO ALSO
INSERT INTO sells
SELECT 'West' AS seller, NEW.property, 'Nono' AS buyer
FROM missile WHERE thing=NEW.property;
-- americans_selling_weapons_to_hostiles_are_criminal
CREATE RULE americans_selling_weapons_to_hostiles_are_criminal__hostile AS
ON INSERT TO hostile
DO ALSO
INSERT INTO criminal
SELECT seller FROM sells, weapon, american
WHERE sells.buyer=NEW.person
AND sells.thing=weapon.thing
AND sells.seller=american.person;
CREATE RULE americans_selling_weapons_to_hostiles_are_criminal__weapon AS
ON INSERT TO weapon
DO ALSO
INSERT INTO criminal
SELECT seller FROM sells, hostile, american
WHERE sells.buyer=hostile.person
AND sells.thing=NEW.thing
AND sells.seller=american.person;
CREATE RULE americans_selling_weapons_to_hostiles_are_criminal__american AS
ON INSERT TO american
DO ALSO
INSERT INTO criminal
SELECT seller FROM sells, hostile, weapon
WHERE sells.buyer=hostile.person
AND sells.thing=weapon.thing
AND sells.seller=NEW.person;
CREATE RULE americans_selling_weapons_to_hostiles_are_criminal__sells AS
ON INSERT TO sells
DO ALSO
INSERT INTO criminal
SELECT NEW.seller FROM american, hostile, weapon
WHERE NEW.buyer=hostile.person
AND NEW.thing=weapon.thing
AND NEW.seller=american.person;
-- entering some facts now:
INSERT INTO missile VALUES('M1');
INSERT INTO enemy VALUES('Nono','America');
INSERT INTO owns VALUES('Nono','M1');
INSERT INTO american VALUES('West');
-- querying the database:
SELECT * FROM criminal;
= 8 ==
If this could be done efficiently, it would allow many interesting
applications -- I guess that
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Nick Rudnick joerg.rudn...@t-online.de wrote: here an inelegant example Based on that example, you should be sure to look at the INHERITS clause of CREATE TABLE: http://www.postgresql.org/docs/current/interactive/sql-createtable.html PostgreSQL has the is a structure built in. That may not get you all the way there, but between that and a few views, you might get close without needing a lot of low level infrastructure work. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Hi Pavel, I guess this represents most exactly what this professor is thinking about -- being able to create methods and types with methods which can be nested -- but syntactical details are of secondary importance. All the best, Nick On 02/01/2011 05:43 AM, Pavel Stehule wrote: Hello it is part of ANSi SQL 2003 http://savage.net.au/SQL/sql-2003-2.bnf.html#method%20specification%20designator 2011/2/1 Pavel Stehulepavel.steh...@gmail.com: 2011/2/1 Robert Haasrobertmh...@gmail.com: On Mon, Jan 31, 2011 at 5:09 PM, Nick Rudnickjoerg.rudn...@t-online.de wrote: Interesting... I remember that some years ago, I fiddled around with functions, operators etc. to allow a method like syntax -- but I ever was worried this approach would have serious weaknesses -- are there any principal hindrances to having methods, if no, can this be implemented in a straightforward way? It would help if you were a bit more specific. Do you mean you want to write something like foo.bar(baz) and have that mean call the bar method of foo and pass it baz as an argument? If so, that'd certainly be possible to implement for purposes of a college course, if you're so inclined - after all it's free software - but we'd probably not make such a change to core PG, because right now that would mean call the function bar in schema baz and pass it foo as an argument. We try not to break people's code to when adding nonstandard features. I has not a standard, so I am not sure what is in standard and what not. It was a popular theme about year 2000 and OOP was planed to SQL3. You can find a some presentation from this time. Oracle implemented these features. J. Melton: SQL:1999: Understanding Object-Relational and Other Advanced Features, Morgan Kaufmann, 2003. CREATE METHOD next_color (n INT) RETURNS INT FOR colored_part_t RETURN SELF.color_id + n SELECT partno, color_id, DEREF(oid).next_color(1) AS next FROM colored_parts some other databases implemented a dereferenced data (it's not only Oracle's subject) http://www.java2s.com/Code/Oracle/Object-Oriented-Database/DEREFDereferencetheRowAddresses.htm Probably DB2 implements this functionality too. See doc for CREATE TYPE statement, REF USING, NOT FINAL, method specification CREATE TYPE type-name ... METHOD attribute-name() RETURNS attribute-type these features are very nice - but is not well documented and probably not used. Pavel -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Hi Peter, Another possibility is foo-bar(baz) This is in the SQL standard underattribute or method reference, but it requires the left side to be of a reference type, which is something that we don't have. I think this is the point where I stopped my efforts in the past -- I guessed that a reference, in PostgreSQL relational algebra, could be a pair of a pg_class oid together with the object's oid (having to query the pg_class oid each time seemed very expensive to me, then). I fiddled around with a little C programming, then I lost confidence in whether I was doing something reasonable -- I was afraid I did not know enough about the internals to predict a convincing outcome. All the best, Nick -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Hi Kevin, this example was for teaching AI students (with limited PostgreSQL knowledge) in a very basic lecture -- I did not want to tweak the SQL semantics too much; just demonstrate why SQL is rightfully called a 4GL language. ;-) Cheers, Nick On 02/01/2011 10:08 PM, Kevin Grittner wrote: Nick Rudnickjoerg.rudn...@t-online.de wrote: here an inelegant example Based on that example, you should be sure to look at the INHERITS clause of CREATE TABLE: http://www.postgresql.org/docs/current/interactive/sql-createtable.html PostgreSQL has the is a structure built in. That may not get you all the way there, but between that and a few views, you might get close without needing a lot of low level infrastructure work. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [pgsql-general 2011-1-21:] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Hello What I know no body is working on SQL/OLB ISO/IEC 9075-10 now. I proposed a 3 years ago a support of methods, but without success. This propose was rejected. There isn't a real interest to implement it from commiters. And I have to say - users doesn't request it too. And there are a few issues with compatibility. That's all what I know. Regards Pavel Stehule 2011/1/31 Jörg Roman Rudnick joerg.rudn...@t-online.de: 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
On Mon, Jan 31, 2011 at 4:34 AM, Pavel Stehule pavel.steh...@gmail.com wrote: What I know no body is working on SQL/OLB ISO/IEC 9075-10 now. I proposed a 3 years ago a support of methods, but without success. This propose was rejected. There isn't a real interest to implement it from commiters. And I have to say - users doesn't request it too. And there are a few issues with compatibility. It seems to me it's a bit unfair to say there isn't real interest to implement it from committers. Plenty of features get implemented that no committer particularly cares about, because a number of committers - including me - spend a good deal of time reviewing and committing patches written by other people which they never would have written themselves. It's true that patches sometimes get swatted down because they are judged to be insufficiently useful or badly design or because they create compatibility breaks, but that's not the same as not interested, which to me implies a sort of purely arbitrary rejection that I try hard to avoid. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
On Mon, Jan 31, 2011 at 3:32 AM, Jörg Roman Rudnick joerg.rudn...@t-online.de wrote: * 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? I don't really know much about ORDBMS / OODBMS functionality; a quick Google search suggests that SQL/OLB is mostly about Java language bindings, and there's a separate project (pgsql-jdbc) which works on PostgreSQL connectivity for Java. As far as changes to the core database are concerned, user-defined functions and operators are not hard to create, but I'm fuzzy on what specifically you want to do. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Interesting... I remember that some years ago, I fiddled around with functions, operators etc. to allow a method like syntax -- but I ever was worried this approach would have serious weaknesses -- are there any principal hindrances to having methods, if no, can this be implemented in a straightforward way? Thank you in advance, Nick On 01/31/2011 03:19 PM, Robert Haas wrote: On Mon, Jan 31, 2011 at 4:34 AM, Pavel Stehulepavel.steh...@gmail.com wrote: What I know no body is working on SQL/OLB ISO/IEC 9075-10 now. I proposed a 3 years ago a support of methods, but without success. This propose was rejected. There isn't a real interest to implement it from commiters. And I have to say - users doesn't request it too. And there are a few issues with compatibility. It seems to me it's a bit unfair to say there isn't real interest to implement it from committers. Plenty of features get implemented that no committer particularly cares about, because a number of committers - including me - spend a good deal of time reviewing and committing patches written by other people which they never would have written themselves. It's true that patches sometimes get swatted down because they are judged to be insufficiently useful or badly design or because they create compatibility breaks, but that's not the same as not interested, which to me implies a sort of purely arbitrary rejection that I try hard to avoid. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Hello Robert, a good moment to clear things up: * Of course, compliance with an ISO-SQL standard is of minimal importance -- I just grabbed it from the docs. * The same holds (in a somewhat weaker way) for Java -- I would even prefer the more general notion type instead of OO, but I am asking in interest of a CS professor I worked for in the past, who is looking for impressive demos of non standard DBMS technology. The students might find resemblance to Java helpful, who knows? * In this regard it is of interest in how far there are principal efficiency problems with the support of (deeply nested) object like structure by the backend, or if the backend may be expected to do this job not terribly worse then more specialized OODMS -- of course, I would be interested in any discussions of these topics... * The same question for doing rule bases on top of the PostgreSQL backend... * For teaching at university courses, on the other hand, efficiency would be of lower interest, so there was an idea that there might be some (possibly toy example like) efforts to tune the frontend into this direction. == Academic prototypes, which preferably do not bring too much overhead for students. Cheers, Nick On 01/31/2011 03:22 PM, Robert Haas wrote: On Mon, Jan 31, 2011 at 3:32 AM, Jörg Roman Rudnick joerg.rudn...@t-online.de wrote: * 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? I don't really know much about ORDBMS / OODBMS functionality; a quick Google search suggests that SQL/OLB is mostly about Java language bindings, and there's a separate project (pgsql-jdbc) which works on PostgreSQL connectivity for Java. As far as changes to the core database are concerned, user-defined functions and operators are not hard to create, but I'm fuzzy on what specifically you want to do. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
On Mon, Jan 31, 2011 at 5:09 PM, Nick Rudnick joerg.rudn...@t-online.de wrote: Interesting... I remember that some years ago, I fiddled around with functions, operators etc. to allow a method like syntax -- but I ever was worried this approach would have serious weaknesses -- are there any principal hindrances to having methods, if no, can this be implemented in a straightforward way? It would help if you were a bit more specific. Do you mean you want to write something like foo.bar(baz) and have that mean call the bar method of foo and pass it baz as an argument? If so, that'd certainly be possible to implement for purposes of a college course, if you're so inclined - after all it's free software - but we'd probably not make such a change to core PG, because right now that would mean call the function bar in schema baz and pass it foo as an argument. We try not to break people's code to when adding nonstandard features. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
On Mon, Jan 31, 2011 at 5:40 PM, Nick Rudnick joerg.rudn...@t-online.de wrote: * In this regard it is of interest in how far there are principal efficiency problems with the support of (deeply nested) object like structure by the backend, or if the backend may be expected to do this job not terribly worse then more specialized OODMS -- of course, I would be interested in any discussions of these topics... I simply don't know what a more-specialized OODBMS would do that is similar to or different than what PostgreSQL does, so it's hard to comment. I don't immediately see why we'd be any less efficient, but without knowing what algorithms are in use on the other side, it's a bit hard to say. * The same question for doing rule bases on top of the PostgreSQL backend... I'm not sure if you're referring to the type of rules added by the SQL command CREATE RULE here, or some other kind of rule. But the rules added by CREATE RULE are generally not too useful. Most serious server programming is done using triggers. * For teaching at university courses, on the other hand, efficiency would be of lower interest, so there was an idea that there might be some (possibly toy example like) efforts to tune the frontend into this direction. You're still being awfully vague about what you mean by this direction. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Robert Haas robertmh...@gmail.com writes: It would help if you were a bit more specific. Do you mean you want to write something like foo.bar(baz) and have that mean call the bar method of foo and pass it baz as an argument? If so, that'd certainly be possible to implement for purposes of a college course, if you're so inclined - after all it's free software - but we'd probably not make such a change to core PG, because right now that would mean call the function bar in schema baz and pass it foo as an argument. We try not to break people's code to when adding nonstandard features. You would probably have better luck shoehorning in such a feature if the syntax looked like this: (foo).bar(baz) foo being a value of some type that has methods, and bar being a method name. Another possibility is foo-bar(baz) I agree with Robert's opinion that it'd be unlikely the project would accept such a patch into core, but if you're mainly interested in it for research purposes that needn't deter you. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
2011/2/1 Robert Haas robertmh...@gmail.com: On Mon, Jan 31, 2011 at 5:09 PM, Nick Rudnick joerg.rudn...@t-online.de wrote: Interesting... I remember that some years ago, I fiddled around with functions, operators etc. to allow a method like syntax -- but I ever was worried this approach would have serious weaknesses -- are there any principal hindrances to having methods, if no, can this be implemented in a straightforward way? It would help if you were a bit more specific. Do you mean you want to write something like foo.bar(baz) and have that mean call the bar method of foo and pass it baz as an argument? If so, that'd certainly be possible to implement for purposes of a college course, if you're so inclined - after all it's free software - but we'd probably not make such a change to core PG, because right now that would mean call the function bar in schema baz and pass it foo as an argument. We try not to break people's code to when adding nonstandard features. I has not a standard, so I am not sure what is in standard and what not. It was a popular theme about year 2000 and OOP was planed to SQL3. You can find a some presentation from this time. Oracle implemented these features. J. Melton: SQL:1999: Understanding Object-Relational and Other Advanced Features, Morgan Kaufmann, 2003. CREATE METHOD next_color (n INT) RETURNS INT FOR colored_part_t RETURN SELF.color_id + n SELECT partno, color_id, DEREF(oid).next_color(1) AS next FROM colored_parts some other databases implemented a dereferenced data (it's not only Oracle's subject) http://www.java2s.com/Code/Oracle/Object-Oriented-Database/DEREFDereferencetheRowAddresses.htm Probably DB2 implements this functionality too. See doc for CREATE TYPE statement, REF USING, NOT FINAL, method specification CREATE TYPE type-name ... METHOD attribute-name() RETURNS attribute-type these features are very nice - but is not well documented and probably not used. Pavel -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Hello it is part of ANSi SQL 2003 http://savage.net.au/SQL/sql-2003-2.bnf.html#method%20specification%20designator 2011/2/1 Pavel Stehule pavel.steh...@gmail.com: 2011/2/1 Robert Haas robertmh...@gmail.com: On Mon, Jan 31, 2011 at 5:09 PM, Nick Rudnick joerg.rudn...@t-online.de wrote: Interesting... I remember that some years ago, I fiddled around with functions, operators etc. to allow a method like syntax -- but I ever was worried this approach would have serious weaknesses -- are there any principal hindrances to having methods, if no, can this be implemented in a straightforward way? It would help if you were a bit more specific. Do you mean you want to write something like foo.bar(baz) and have that mean call the bar method of foo and pass it baz as an argument? If so, that'd certainly be possible to implement for purposes of a college course, if you're so inclined - after all it's free software - but we'd probably not make such a change to core PG, because right now that would mean call the function bar in schema baz and pass it foo as an argument. We try not to break people's code to when adding nonstandard features. I has not a standard, so I am not sure what is in standard and what not. It was a popular theme about year 2000 and OOP was planed to SQL3. You can find a some presentation from this time. Oracle implemented these features. J. Melton: SQL:1999: Understanding Object-Relational and Other Advanced Features, Morgan Kaufmann, 2003. CREATE METHOD next_color (n INT) RETURNS INT FOR colored_part_t RETURN SELF.color_id + n SELECT partno, color_id, DEREF(oid).next_color(1) AS next FROM colored_parts some other databases implemented a dereferenced data (it's not only Oracle's subject) http://www.java2s.com/Code/Oracle/Object-Oriented-Database/DEREFDereferencetheRowAddresses.htm Probably DB2 implements this functionality too. See doc for CREATE TYPE statement, REF USING, NOT FINAL, method specification CREATE TYPE type-name ... METHOD attribute-name() RETURNS attribute-type these features are very nice - but is not well documented and probably not used. Pavel -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
