Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA08743; Fri, 15 Nov 91 16:32:37 -0800
Message-Id: <9111160032.AA08743@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: POSTGRES questions
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of "Mon, 04 Nov 91 08:04:19 PST."
             <9111041604.AA01205@postgres.Berkeley.EDU> 
Date: Fri, 15 Nov 91 16:32:15 PST

In message <9111041604.AA01205@postgres.Berkeley.EDU> you write:

> 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?

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.

> 2. What meta-data are kept on rules?  (e.g., creator, purpose, etc.)  How
> 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).

> 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? 

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.

> 4. Does use of the nested dot notation result in joining or in pointer
> 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.

> 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?

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
mer@postgres.berkeley.edu