Re: Python 3.1 support

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: James Pye <lists(at)jwp(dot)name>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Python 3.1 support
Date: 2009-11-19 18:32:58
Message-ID: 1258655578.26726.13.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On ons, 2009-11-18 at 13:36 -0700, James Pye wrote:
> On Nov 18, 2009, at 8:37 AM, Peter Eisentraut wrote:
> > The question is whether it helps the user, not the implementer.
>
> Sure, but do you have a patch waiting to implement tracebacks?
>
> I'd argue the reason it's never been done is due to the way procedures are currently managed in PL/Python. And *without some significant refactoring*, any patch fully implementing tracebacks is going to be a seriously ugly hack.
>
> What helped the implementer here would help the user.

But you wouldn't, for example, get away with breaking SQL (or even
improving it incompatibly) to facilitate a better elog.

> > As far
> > as I can tell, it just creates more typing for no benefit whatsoever.
>
> "def main(*args):" is annoying, but not entirely lamentable...
> It's explicit, as well(no need to document munging that occurs behind the scenes).
>
> Also, compare the cases where you need to cache some initialized data:
>
> if 'key' not in SD:
> ...
> SD['key'] = my_newly_initialized_data
> ...
>
>
> With function modules, SD is not needed as you have your module globals to keep your locally cached data in:
>
> ...
> data = my_newly_initialized_data
>
> def main(*args):
> ...

I can see that this creates other options for structuring code, but it
doesn't actually match my way of thinking. (Obviously, I'm biased, but
anyway.) I think of a PL/Python function as a Python script file stored
in the database. When you call it, arguments are passed just like a
Python script receives arguments from the shell. When Python scripts
want to share data, they might use a file (or perhaps a database server
in advanced cases) and do

if not file exists:
create the file
fill it with data

This is in my mind quite analogous to how the SD business works.

The analogy to your approach, as I understand it, would be that multiple
instances of the same script file will automatically share their global
variables. That could be quite interesting, actually, but it's not how
it works, and in most cases it's better that way.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-11-19 18:43:15 Re: Python 3.1 support
Previous Message Peter Eisentraut 2009-11-19 18:21:01 Re: Python 3.1 support