Re: Learning curves and such (was Re: [HACKERS] pgFoundry)

[Dmitriy Letuchy]

Tom Lane [EMAIL PROTECTED]
Date: Tue, 17 May 2005 01:32:03 -0400

 As against that I notice some new arrivals proposing to add deductive
 reasoning to Postgres:
 http://archives.postgresql.org/pgsql-hackers/2005-05/msg01045.php
 or implement SQL99 hierarchical queries:
 http://archives.postgresql.org/pgsql-hackers/2005-05/msg01089.php
 
 I might be wrong, but I'll bet lunch that neither of those projects will
 come to anything.  You can't run before you learn to crawl.

The main advantage of deductive reasoning implementation I propose 
is in fundamental extension of database query language, I don't propose 
to extent SQL with some cumbersome constructions, for example, like WITH 
to express recursive queries (inefficiency of such constructions can be easily 
seen if you try to express a bit more complex recursive query then finding 
ancestors, e.g. query which finds minimal paths). 

Also it should be mentioned that original query language (SQL) de facto 
remains without great changes, the logic program which defines predicates 
(intensional relations) is located in the system table (there can be put 
the name and both the text and inner code of logic program). When we want 
to get intensional relation we simply write in SQL query the name of the 
logic program (deductive database) and the name of the predicate with the 
list of arguments. This syntax is identical to the syntax of table function 
calling with the schema name.

Regards, Dmitriy

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[HACKERS] postgreSQL as deductive DBMS

[Dmitriy Letuchy]

Hello all,

I have some ideas how to increase expressive power of the PostgreSQL query 
language. It is not a secret that SQL is very poor to express many important 
queries, and we have to use means of procedural extensions of SQL to realize 
them. However this is not good idea to split query language into two parts 
(declarative and procedural) at least because query language must finally 
operate with the objects of data domain, not with the bits the objects consist 
of. Thus another alternative to increase expressive power of query language is 
to develop its declarative (i.e. nonprocedural) part. And here we come to 
deductive database (DDB) with its logic language Datalog.
Every logic query is a set of inverse implications, which describe what to 
find (i.e. exactly declarative approach) and not how to find (i.e. exactly 
procedural approach). We can translate logic query into set of SQL commands and 
then run them to get result. Some samples with the DLQ compiler can be 
downloaded from www.datalab.kharkov.ua (DLQ is our original version of Datalog 
which was developed with the purpose to tie closely RDB and DDB).
Now some words about what must be done to realize described feature. The 
simple quickest way but the way without future is to write language handler. 
Other more correct way is to slightly extend DML part of SQL and more 
essentially extend DDL. For example, we have relation Inheritance with two 
attributes ClassID and ParentID. Now we want to define all descendants or all 
ancestors. For this goal we define predicate inheritance_all with the next two 
rules (i.e. inverse implications):

inheritance_all(ClassID, ParentID) :- inheritance(ClassID, ParentID);
inheritance_all(ClassID, ParentID) :- inheritance(ClassID, X), 
inheritance_all(X, ParentID).

We put this rules into database and call, for example, the next SQL 
commands:

--   find all descendents
SELECT * FROM ddb_name.inheritance_all(_, _) 

-- find all descendents from ParentID = 1
SELECT * FROM ddb_name.inheritance_all(_, 1)

where ddb_name is the name of deductive database where our rules are kept,  _ 
designates anonymous variable (see Prolog notation for details).

Regards, Dmitriy

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings