Greetings,
For a big application, I want to generate reports from the database and
keep these on-line as long as they reflect the actual contents of the
database. I only want to regenerate the reports when needed, i.e.,
when the database contents have changed.
I'm sure PostgreSQL can tell me when
Doug McNaught <[EMAIL PROTECTED]> writes:
> I would put an AFTER trigger on all the tables concerned that
> inserts a row into an audit table. [...] Audit tables are useful for
> other things too, if you can afford them.
I think auditing is much too heavy for something simple as finding the
last
Doug McNaught <[EMAIL PROTECTED]> writes:
> Yeah, LISTEN/NOTIFY is definitely a lighter-weight solution--I didn't
> think of that before.
LISTEN/NOTIFY looks like a synchronisation mechanism. You can notify a
subscriber that something happened. But in my case, the report
generating program runs on
Karsten Hilbert <[EMAIL PROTECTED]> writes:
> However, given your above description why does it not
> suffice to regenerate the report whenever the report
> generator connects ? If you want to do so only when the
> table has actually changed you might add a last_modified
> timestamp column with a
Luuk Jansen <[EMAIL PROTECTED]> writes:
> How can I update the structure on the production server to reflect the
> database on my test machine in an easy way with preservation of the data
> on the production server. There are no major changes in the fields types
> etc., mainly additions/deletions
