Re: Calling Python functions with parameters
От | brian |
---|---|
Тема | Re: Calling Python functions with parameters |
Дата | |
Msg-id | 4884BD41.1060808@zijn-digital.com обсуждение исходный текст |
Ответ на | Calling Python functions with parameters ("Jerry McRae" <2567jl03@sneakemail.com>) |
Список | pgsql-general |
Jerry McRae wrote: > I am having a problem with the simplest of Python functions, so I must be > doing something wrong. After hours of searching and trying many options, I > need the key that my puny brain is missing here. > > I cannot pass parameters to a plpythonu function. I have tried within psql > and with pgAdmin III (which adds IN or INOUT to the parameter list - which I > can't find documented). I'm an advanced Python programmer but a beginning > PostgreSQL user. > > Here is what I have, which I copied almost verbatim from example code: > ---------------------------- > test_dev-# \p > create or replace function testf5i(a integer,b integer) > RETURNS integer AS $$ > if a > b: > return a > return b > $$ language plpythonu > > > test_dev-# \g > CREATE FUNCTION > test_dev=# select testf5i(1,2); > ERROR: plpython: function "testf5i" failed > DETAIL: exceptions.NameError: global name 'a' is not defined That looks like the same error I received in my first attempts at plpython. After muddling with it for some time (and this was my first practical Python code at all, so you can imagine how confused I was), I added (the equivalent to your code) at the beginning: a = a b = b As ridiculous as that looks, it's what worked for me. Although, function contained a class with several methods (the function creates "slugs" on the fly from proper names for use in URLs, eg. Élisabeth Carrière -> elisabeth_carriere). So, maybe my own problems were related to that. PlPython remains a mystery to me, in many respects. It's certainly *not* the best way to learn Python. > PS. What I need to do, which I also could find not examples on the mailing > lists or the Internet, is to de-normalize some tables (user, addresses, > phones, emails) into one big view and then update the proper tables upon > updates. The web application then can just get one row and not have to deal > with all the different tables > > ... > > (And I'm surprised that I could find no examples of anyone already doing > this? Is there something inherently wrong with this approach?) Perhaps it's simply not worthwhile. That seems like a great deal of work just to avoid having to deal with several tables. (I didn't end up using my slug-creator function, myself, and moved that logic into the application scripts.) b
В списке pgsql-general по дате отправления: