Postgres PL/Python

[Ksenia Marasanova]

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.

 

[Mike Meyer]

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

 

[Jorge Godoy]

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,