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?)