Re: Python 3.1 support

Поиск
Список
Период
Сортировка
От James Pye
Тема Re: Python 3.1 support
Дата
Msg-id 61B9341C-E855-4E5D-89E3-EBE1F27562D8@jwp.name
обсуждение исходный текст
Ответ на Re: Python 3.1 support  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Python 3.1 support
Список pgsql-hackers
On Nov 13, 2009, at 4:47 AM, Peter Eisentraut wrote:
> Has this list of gripes ever been brought up and discussed in this
> forum?


Some are TODOs, so in part by other people. Some were briefly touched on in the recent past discussions(around the time
thatI announced the WIP). Native typing vs conversion, function fragments vs function modules. 
I don't think native typing has seen any actual discussion, but I do recall mentioning it as something that I wanted to
do(implicitlygriped?). 

...

There is a difference in the situation from the discussion before. Prior, it was, "I would like to implement a new PL
forPython 3 with these features", and now, it is, "I have implemented a new PL for Python 3 with these features". 
Simply, -hackers can choose among moving forward with Python 3 support in plpython or going with "plpython3" or even
both,I suppose(?). Naturally, I'm biased toward something that involves plpython3, so I don't think I can(should?) be
ofmuch help to -hackers as a Python & PG user in any such decision. Of course, excepting the provision of
justificationsfor my implementation/design choices... 


I would really love to see some input from Python users.


I certainly don't want to waste time trying to get something into pgsql that Python users don't want.


[here's a gripe that I haven't brought up as I think it is a matter of taste]

I find (plpython) trigger functions to be a bit odd. I think it's the way in which manipulation/suppression decisions
aremade in BEFORE ROW triggers(return "OK", "SKIP", etc).. [label this as opinion at this point as I have yet to be
ableto nail down what, specifically, is "wrong" or un-pythonic about them.] 

Also, having distinct entry points to handle trigger events helps reduce potential errors by forcing the user to
explicitlystate the events that the trigger function can handle. Currently, in plpython, users *should* do sanity
checks.

Function modules opened the door for implementing this in a natural way, multiple functions(entry points) in the
functionmodule. 

http://python.projects.postgresql.org/pldocs/plpython3-programming.html#PLPYTHON3-FUNCTIONS-TRIGGERS

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

Предыдущее
От: Hitoshi Harada
Дата:
Сообщение: Re: Aggregate ORDER BY patch
Следующее
От: nw@hydaspes.if.org
Дата:
Сообщение: Re: next CommitFest