Re: Timing of notice delivery

"Donald Fraser" <postgres@kiwi-fraser.net> wrote:

> If its an identification issue, you can always work out which
> notifications are "self-notifications" via the PID

No, it's strictly a timing issue.  Can the JDBC client which has
just committed a transaction count on getNotifications returning all
relevant notifications from that transaction?  The answer is yes,
which is convenient for us.  The use case is that we will have
triggers firing at the PostgreSQL level, and we don't want the
application to have to be aware of what triggers are there or to
make any assumptions about what these triggers will do; but we want
the JDBC client to be notified about what they actually *did* -- so
that GUI components reflecting the data modified by the triggers can
be updated.

Of course, ultimately we would like to get to a point where all
users displaying relevant data are updated quickly and
automatically, but there are performance considerations to that
which haven't been worked out entirely.  Right now we just want to
make sure that the user making the base change gets immediate
feedback on all side-effects.  This has already been happening
through a Java tier just above the database, but we've decided to
commit to PostgreSQL rather than maintaining database independence,
which allows us to push some of this down to the database level.
We're just trying to work out how to maintain existing functionality
during the switchover, which we've decided to do incrementally, over
the course of a few years -- although this first step of converting
the triggers and stored procedures to PostgreSQL triggers and
functions needs to be done in a single application update before we
do much else.

Ultimately, this will save us from having to maintain a lot of
home-grown infrastructure.  We currently write all our triggers and
stored procedures in an ANSI-SQL-based format, parse that and
generate Java classes to implement the triggers and stored
procedures in that intermediate level.  Even if we need to patch
PostgreSQL here and there, the work should be pretty minimal
compared to what we do now.  Fortunately , it's been pretty
reasonable to create a tree-walker for the tree emitted from our
current parser which emits PostgreSQL functions and triggers.  :-)

But I digress...  Thanks for the suggestion, anyway.

-Kevin