Re: [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)

From: Nick Rudnick <joerg(dot)rudnick(at)t-online(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Date: 2011-02-01 20:54:10
Message-ID: 4D4872F2.4020501@t-online.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 02/01/2011 03:36 AM, Robert Haas wrote:
> On Mon, Jan 31, 2011 at 5:40 PM, Nick Rudnick<joerg(dot)rudnick(at)t-online(dot)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 e.g., in combination with the XML
functionality, a big part of semantic web engine functionality might be
given. I am also more optimistic in this case, as I guess relational
algebra is much closer related to Datalog logic programming (which seems
to be gaining more interest lately) than to OO.

>> * 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".
>
Please excuse -- I cannot speak for this professor... his other option
is using Oracle for teaching, which might support ORDBMS functionality
slightly more -- anything more interesting (for teaching purposes!!!)
would speak for PostgreSQL.

Cheers, Nick

Attachment Content-Type Size
ForwardChaining.sql text/x-sql 2.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2011-02-01 20:56:17 Re: REVIEW: PL/Python validator function
Previous Message Christopher Hotchkiss 2011-02-01 20:51:47 Re: Authentication Enhancement Proposal