Re: plpython3

Поиск
Список
Период
Сортировка
От David Blewett
Тема Re: plpython3
Дата
Msg-id 9d1f8d831001171415v2f78b339o3f071a6280c763dd@mail.gmail.com
обсуждение исходный текст
Ответ на Re: plpython3  (James William Pye <lists@jwp.name>)
Список pgsql-hackers
On Sun, Jan 17, 2010 at 4:07 PM, James William Pye <lists@jwp.name> wrote:
> The effect of this is that every time the FUNCTION is called from PG, the import statements are ran, a new class
object,UrlOpener, is created, and a new function object, translate, is created. Granted, a minor amount of overhead in
thiscase, but the point is that in order to avoid it the author would have to use SD: 
>
> if "urlopener" in SD:
>  UrlOpener = SD["urlopener"]
> else:
>  class UrlOpener(urllib.UrlOpener):
>  ...
>  SD["urlopener"] = UrlOpener
>
> While some may consider this a minor inconvenience, the problem is that *setup code is common*, so it's, at least, a
ratherfrequent, minor inconvenience. 
>
>
> With function modules, users have a module body to run any necessary setup code.

Coming from a Python developer perspective, this is indeed an
improvement. I always thought the whole SD/GD thing was a little odd.
Doing the setup at the module level and relying on the interpreter to
keep it cached is much more "Pythonic" and is a common idiom.

David


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: is this a bug?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Patch: Remove gcc dependency in definition of inline functions