Using stored procedures as an API to the database is a perfectly
acceptable way of doing things, and provides some nice benefits:
You can lock out all other access to tables. This limits what can be
done if the application gets compromised.
It means you don't have to worry about people embedding SQL into the
bowels of the application.
It provides a well-defined API into the database.
As an added bonus, in 8.1 there is syntax checking done on
functions when they are created. This makes catching bugs much easier...
previously you'd have to actually run the code to see if there were any
syntax errors. Now, if you use functions, syntax errors will be found as
soon as you load the code into the database. This feature alone makes
using stored procs as an API worth it.
On Wed, Jan 11, 2006 at 05:13:01PM +0000, Marcos wrote:
> Hi,
>
> I'm developing one application using this wonderful Database, and I've
> like of use the concepts correctly.
>
> Then, i decided that all my SQL statements will be in database using the
> procedure language (plpgsql or plpython), I go create functions for all
> interactions in database, and use in the my application the SELECT for
> call him.
>
> Is its the correct way of working? Or the correct way is create
> procedure functions for big and complex statements?
>
> The application will work with a large Database and will have many
> simultaneous access.
>
> Very Thanks!!!!
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461