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 по дате отправления: