Tony Caduto schrieb: > Randal L. Schwartz wrote: > >> I fear for the future. >> >> Did someone forget what a "database" is for? >> > > You have nothing to fear but fear itself.... > (FDR http://historymatters.gmu.edu/d/5057/) > > Let us see why this might be handy(sending a email or connecting to a > socket server). > > The email function would be handy to send a notifiction of a certain > event, like a trigger. hmm.. a 60 day notifcation trigger fires on a > financial application, some one needs to be notified. > > A real world example of the socket server would be for a notification > system for Pro FTP (which has pg integeration). A file comes in, Pro > FTP writes it to the Postgresql based log table, a trigger fires that > the log has been updated for a new file upload, the PL-perl function > then connects to the pop up notification server and sends a unicast > message to the users connected to the popup notification server. > hmm..pretty handy, you just extended Pro FTP with out having to hack the > Pro FTP source. > > This is actually in use in a large corporate setting. while this might > not be a good idea for something out on the internet because of email > latencies etc, it does work extremely well in a setting where that is > not a issue. > And you are sure you can handle a few hundred thousands emails in your incoming due to a non context aware process which is sending mail? There is no such thing like a 60 day trigger either ;) In short its usual better to connect with an application to the database and handle all that asynchronously - with all the error handling and sanetizing. You can send mail from server but you really should not :-) (Another hint regarding mail: if you send mail to an event and then the transaction rolls back - how to you hold back the email? And if sending/connection to the mta fails, do you want your transaction roll back?)
