Re: Batch Operations - Mailing list pgsql-hackers

From Christopher Browne
Subject Re: Batch Operations
Date
Msg-id m34r0q8gmh.fsf@chvatal.cbbrowne.com
Whole thread Raw
In response to Batch Operations  ("Rahul_Iyer" <rahul_iyer@persistent.co.in>)
List pgsql-hackers
After takin a swig o' Arrakan spice grog, pgadmin@pse-consulting.de (Andreas Pflug) commented...:
> This sounds like that "Scheduled Jobs" task thread that was
> discussed May13th. The essence was that it would be nice to have,
> but nobody seems to work on this at the moment.

What I didn't point out was that this is the sort of thing that
wouldn't be at the "database" level, but rather would be suitably
implemented as part of some form of "application server."

Consider: There may be automated processes of various kinds:

-> Processes that do statically defined updates (e.g. - purge out  old data);

-> Processes that read some data and transform it on a regular basis;

-> Processes that generate reports on a timed basis.

The first sort of process might be amenable to being done inside the
database.

But the second one isn't; it requires having some code that reads the
input.  The third one also isn't; it requires having some sort of
"reporting framework," including such things as [Defining Parameters],
[Formatting Output], and [Spooling Output], none of which are
particularly amenable to being handled in the database engine.

I wouldn't contemplate pushing that all into PostgreSQL; it's
appropriate to implement alongside in some form of "application
server."

I should have been more clear about intent there; this is all "good
stuff," but not things I'd expect to see added in 7.5 or necessarily
ever.
-- 
let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];;
http://www.ntlug.org/~cbbrowne/lsf.html
Sex is the mathematics urge sublimated.
-- M. C. Reed.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 7.4Beta1 hang?
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: getting confused parsing ACLITEMS...