Subject: POSTGRES questions

From: [email-masked] (Len Seligman)
Date: Mon, 4 Nov 91 08:04:19 -0800

I want to use POSTGRES to conduct some research on integrating
knowledge-based systems and databases.  After having read the 3.0 manual once
through, here are some questions:

1. I want to monitor a Postgres DB for certain conditions 
and notify my application
whenever those conditions are satisfied.  How do I handle the routing of
messages from my alerter rules?  I don't want to have to hand code all that
information on the right-hand side of every alerter rule.  Can I use portals?
(Note that my application is one which potentially could be running
continually.  Therefore, I can't make my application one large transaction.)
Does this require the (as-yet-unsupported) "attachas" command?

2. What meta-data are kept on rules?  (e.g., creator, purpose, etc.)  How
can this meta-data be queried?

3. Can rules be modified (e.g., to change the message produced by an
alerter rule, or to slightly modify the triggering condition)?  Can
they be activated and deactivated, as in HiPAC?  Or must they be deleted and 
recreated instead? 

4. Does use of the nested dot notation result in joining or in pointer
chasing?  (e.g., emp.dept.mgr.name)

5. Since multiple inheritance is supported (a la CLOS), how is the 
precedence order determined?  Also, is there any notion of before,
primary, and after methods as in CLOS?  Or is it the case that for any
given object and method, a single function will be selected and executed?
Thanks,

Len Seligman
The MITRE Corporation			(703) 883-5975
7525 Colshire Drive W418		FAX: (703) 883-6435
McLean, VA 22102			email: [email-masked]

---

From: postarch (Postgres Mailing Archive)
Date: Fri, 15 Nov 91 16:32:15 PST

> Does this require the (as-yet-unsupported) "attachas" command?

You currently cannot use portals for this.  We are in the process of producing
a design spec for asynchronous portals to handle potential returned results
generated asynchronously from rules.  It's uncertain when this will actually 
be implemented, probably by next March when the version 4 release is scheduled 
to come out.

> can this meta-data be queried?

All of the query-able meta data on rules is kept in system catalog relations
pg_prs2rule and pg_rewrite.  The former is for instance rules and the latter
for rewrite. pg_rewrite stores the rule name, class on which it's defined,
the attribute on which its defined, an event type id (rewrite uses a strange
encoding, while instance uses characters R - retrieve A - append etc.),
whether or not it's an instead rule, and pieces of the parse tree that describe 
the event qualification and action.  pg_prs2rule has analogous attributes.
Instance rules also maintain two other catalogs pg_prs2plans and pg_prs2stubs
but these are for internal use and don't contain meta-data interesting
to the user (e.g. pg_prs2plans holds string representations of query plans 
for rule bodies).

> they be activated and deactivated, as in HiPAC?  Or must they be deleted and 

Once defined rules can't be modified.

Barring some ugly hack that I'm overlooking, they can't be dis/enabled
they must be removed and recreated to get that effect.

> chasing?  (e.g., emp.dept.mgr.name)

We do no pointer chasing, even the mention of such practices sends shivers
down the spine of professors of the relational model.  Nested dot expressions 
mean the implicit execution of a postquel function or query rewrite rule.  
Depending on the function or rule this could mean a join.

> given object and method, a single function will be selected and executed?

We disallow multiple inheritance if there is ever a conflict in the attribute
names.  Currently defining a method means defining a postquel function on a
class or (loosely speaking) a c function with the class as the first argument.  
In the first case you are effectively adding an attribute to the relation and 
the method is inherited through the same mechanism of attributes.  In the 
second case you are registering a function so there can be only one by that 
name.  Since no two inherited methods can have the same name there is never any 
ambiguity.

Jeff Meredith
[email-masked]