Postgres PL/Python

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Ksenia Marasanova

    #1

    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
  • Mike Meyer

    #2
    Re: Postgres PL/Python

    Ksenia Marasanova <ksenia.marasan ova@gmail.com> writes:[color=blue]
    > 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)?[/color]

    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.
    [color=blue]
    > 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?[/color]

    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 <mwm@mired.or g> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

    Comment

    • Jorge Godoy

      #3
      Re: Postgres PL/Python

      Mike Meyer <mwm@mired.or g> writes:
      [color=blue]
      > 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."[/color]

      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 <godoy@ieee.org >

      Comment

      Working...