Re: Python 3.1 support

From: James Pye <lists(at)jwp(dot)name>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Python 3.1 support
Date: 2009-11-16 01:39:33
Message-ID: 06048D1F-5C48-425F-95DC-FC6B4B5D3724@jwp.name
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Nov 15, 2009, at 6:37 AM, Peter Eisentraut wrote:

> but these two features don't excite me at all,

hrm.. at all?

I can see how function modules might look like a half-step backwards from function fragments at first, but the benefits of a *natural* initialization section (the module body) was enough to convince me. The added value on the PL developer's side was also compelling. Tracebacks were trivial to implement, and there is no need to munge the function's source. It seemed like a win all around...

AFA native typing is concerned, I think the flexibility and potential it offers is useful, no? Already, plpython3 provides properties on PG's datetime types to access the date_part()'s of the object.

OTOH, for folk who primarily use the PL to access functionality in Python modules(bindings), native typing may be of no direct utility as they will likely need to convert anyways. (If that's your common use-case, then the absence of interest in native typing is quite understandable.)

[looking at the PL/Python todo list..]

Excepting DB-API and trusted, I believe all the current PL/Python TODOs are fulfilled or N/A in plpython3... ugh, the docs are not yet complete, but I like to think of them as "better" anyways. :P

> the pain of dealing with a second implementation.

What pain are you anticipating? Maintenance?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hitoshi Harada 2009-11-16 01:40:33 Re: Aggregate ORDER BY patch
Previous Message Robert Haas 2009-11-16 01:35:30 Re: named parameters in SQL functions