From: | Tony Caduto <tony(dot)caduto(at)amsoftwaredesign(dot)com> |
---|---|
To: | Tino Wildenhain <tino(at)wildenhain(dot)de> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: sending mail from Postgres |
Date: | 2005-12-28 22:55:27 |
Message-ID: | 43B317DF.6060400@amsoftwaredesign.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Yep, we try to keep all the sql in functions/procedures as it makes
updates a lot easier and keeps the business logic seperate from the
client application.
We use native compiled front ends (Delphi) for windows and Lazarus for
everything else. When you keep everything in a function/proc it makes
it a piece of cake to tweak the business logic or update it from a dev box.
I know a lot of coders who use PHP etc put the sql right in the scripts
and that is fine since you can update it without a recompile.
If you catch the errors in you functions and recover from them you won't
need to roll anything back, you would just do a commit.
Later,
Tony
> Actually not. There are several reasons why a transaction can
> abort - do you cover all your queries in functions?
> This would be a little bit unusual, to say at least.
> Every query can fail. Its useless to do error
> catching in your app if the server actually rolled back
> due to an error and yet sent the mail :-)
>
> Just curious, what framework do you use for your frontend
> applications?
>
> Have a nice day
> Tino
>
From | Date | Subject | |
---|---|---|---|
Next Message | Trent Shipley | 2005-12-29 00:03:07 | Re: WAL logs multiplexing? |
Previous Message | Chris Travers | 2005-12-28 22:39:52 | Re: FW: Re[2]: new beginner to postgresql. Looking at |