From: "Jim Starkey" <jas@...>

> But, please, go ahead and sketch an alternative scheme.

Okay!

1. Modify POST_EVENT syntax to the following:

POST_EVENT '<name-string>'
[ SET <identifier> = <expression> [, <identifier> = <expression> ...] ]

This syntax is similar to that of the SQL UPDATE statement.

2. The engine treats this as if a query had generated a result set of one
row. It keeps an XSQLVAR structure around to contain the values posted with
the event. The datatypes of the XSQLVAR are determined implicitly by the
types of expressions that the POST_EVENT passed.

3. Any client that was waiting for the event must call isc_dsql_fetch() to
get the return data. The statement handle that the client uses for this
purpose is returned by a new API function isc_event_dataset(const char
*event). For example:

isc_stmt_handle st = isc_event_dataset("STOCK");
status = isc_dsql_fetch(status_vector, &st, 1, &out_xsqlda);

The server provides the mapping between string names of events and fake
statement handles, to allow the fetch to work.

4. If there is no associated data for the event, isc_dsql_fetch() returns
100, just like any other result set. If the event was posted multiple
times, there are multiple rows of data available for the given event name.
isc_dsql_fetch() returns 0 in this case, indicating that there are more rows
in the result set.

Issues:

o It takes time to fetch these result sets, does this mean the data are
stale? It depends on the nature of the data. One could imagine an
asynchronous "queued" event mechanism, where you connect to the database and
get all the events that occurred while you were disconnected. It would be
no worse than that. The application designer would have to keep this in
mind, and not assume that the data returned by the event corresponds to
committed data in the database.

o Are rows of the dataset ordered in chronological order? Not by guarantee.
If this is important, the post_event should pass some extra data like a
timestamp or a gen_id() value.

o How long does the server keep the event's dataset around? The server
knows which clients have registered an interest in the named event. If all
clients have either fetched the data or disconnected, then the server can
discard the dataset. I assume there is a similar policy currently in the
server for expiring conventional datasets.

o Can Event-datasets include Blobs? No, only data that can be stored in the
XSQLVAR by value can be passed through the Event mechanism. Nothing that
requires reading other database pages is allowed.

o Is there a cursor or an RDB$DB_KEY for an Event dataset? No. The dataset
doesn't correspond to physical storage, nor can you update it.

o What if I'm in a loop fetching multiple datasets because the event was
posted multiple times, and another event is posted? ... If you're in an
event callback, you should disable asynchronous notification, just like the
rules for writing signal handlers. The extra event dataset could make a
fetch return 0 when it would have returned 100. It's possible to get into a
race condition here, but not likely.

o Does this mean I can "poll" an event dataset without having registered for
the event notification? Sure, but the engine won't know to keep the dataset
for you; it might expire it, leading to undefined results.

o What about scrolling backward through the event dataset someday when we
have scrollable cursors? No; once you've fetched a row, it's subject to
garbage collection. Fetch operations other than "next" for the fake
statement handles should return an error.

Bill Karwin