By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,898 Members | 1,162 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,898 IT Pros & Developers. It's quick & easy.

Postgres PL/Python

P: n/a
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
Share this Question
Share on Google+
2 Replies


P: n/a
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

P: n/a
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.