471,123 Members | 791 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,123 software developers and data experts.

Postgres PL/Python

Hi,

I wonder if anyone on this list is using Python as Postgres
procedural language. I can't find a place for it i my mind. How would
a typical MVC web application benefit from it (besides performance)?
I understand from the docs that Postgres 7.4 has PL/PythonU -
unlimited functionality. It sounds like I have the whole Python
available in Postgres. That means big parts of application logic can
be moved to stored procedures, and dummy SQL layer becomes something
else... sounds scary. Any opinions on this?

Thanks.

--
Ksenia
Sep 15 '05 #1
2 2479
Ksenia Marasanova <ks***************@gmail.com> writes:
I wonder if anyone on this list is using Python as Postgres
procedural language. I can't find a place for it i my mind. How would
a typical MVC web application benefit from it (besides performance)?
Your typical MVC web application hasn't got the foggiest about whether
the code that handles it's HTTP request is running in a stored
procedure or a client, and has no way of even finding out. So there's
no way they can "take advantage" of them.

At first glance, the performance difference is as likely to be
negative as it is to be positive, so avoid premature optimizations.
I understand from the docs that Postgres 7.4 has PL/PythonU -
unlimited functionality. It sounds like I have the whole Python
available in Postgres. That means big parts of application logic can
be moved to stored procedures, and dummy SQL layer becomes something
else... sounds scary. Any opinions on this?


Sounds like something that's good for your job security.

That you can now do stored procedures in Python shouldn't have any
effect on whether you decide to implement some function in your
application as a stored procedure or not. Unless there's something
really screwy about PL/Python, anyway.

Whether or not you use stored procedures is almost religious in
nature. Google for "stored procedures", and you'll find opinions
ranging from "never use them at all" to "use them whenever you
possibly can."

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Sep 16 '05 #2
Mike Meyer <mw*@mired.org> writes:
Whether or not you use stored procedures is almost religious in
nature. Google for "stored procedures", and you'll find opinions
ranging from "never use them at all" to "use them whenever you
possibly can."


Also there's the problem of performance. If you can write an SQL function
(that's how PostgreSQL calls its stored procedures) instead of a Python
function, chances are that the query analyzer will be able to do a better job
optimizing it than with Python.

From some talk on IRC with PostgreSQL people, I got the following impression
(in order of better performance to worse performance):

- C
- SQL
- plpgsql
- plpythonu

YMMV.
Ah! And I'm the one of "use them whenever you can" people. :-) It reduces a
lot of code and make system less prone to errors when you have multiple
interfaces (besides making it easier to fix / add database logic).
Be seeing you,
--
Jorge Godoy <go***@ieee.org>
Sep 16 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Ravi | last post: by
1 post views Thread by Steve | last post: by
1 post views Thread by Roland Heiber | last post: by
3 posts views Thread by Michael Lang | last post: by
4 posts views Thread by Lynn.Tilby | last post: by
24 posts views Thread by Henrik Steffen | last post: by
9 posts views Thread by Reid Priedhorsky | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.