Re: Python 3.1 support - Mailing list pgsql-hackers

From James Pye
Subject Re: Python 3.1 support
Date
Msg-id 61B9341C-E855-4E5D-89E3-EBE1F27562D8@jwp.name
Whole thread Raw
In response to Re: Python 3.1 support  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Python 3.1 support
List 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 by date:

Previous
From: Hitoshi Harada
Date:
Subject: Re: Aggregate ORDER BY patch
Next
From: nw@hydaspes.if.org
Date:
Subject: Re: next CommitFest