List is incomplete, will be adding more topics shortly
At a minimum you should be able to handle select/project/join queries with simple join conditions and two relations. Ideally you should be able to handle any number of relations and aggregation also.
Don't worry too much about efficiency of your incremental view maintenance implementation, but extra marks for taking care of join orders in view maintenance.
You can assume that the update can be sent over a socket connection (which the subcriber should be listening for), or even over http (using a servlet at the subcriber).
Make sure that if the subscriber is down temporarily, when it can be accessed again a backlog of updates is sent (unless the backlog is too big). Note that replication is not transactional. To find out when a relation is updated, see the tips in the materialized view maintenance project. Note that updates by uncommitted transactions may be sent as a result. Extra credits for ensuring that only committed updates are sent to the subscriber.
Tip: Slony-I is a replication software designed for postgresql. It is not full featured compared to pub-sub support in commercial databases, but take a look at it to see what features it supports. (You don't have to implement all of them!)
Year Q1 Q2 Q3 Q4 ------------------------ 2005 11 22 15 25 2006 10 20 18 27when we apply pivot[Year][Quarter](sales) on a relation sales of the form
Year Quarter Sales 2005 Q1 11 2005 Q2 22 2005 Q3 15 ...