Python 3.1 support
in [PgSql]
|
Prev: New VACUUM FULL
Next: Aggregate ORDER BY patch
From: James Pye on 19 Nov 2009 12:01 On Nov 19, 2009, at 3:12 AM, Peter Eisentraut wrote: > The other approach, which is what James Pye's > new implementation proposes (as I understand it), is to convert > PostgreSQL types into specially made Python objects, such as > Postgres.types.record or Postgres.types.timestamp. Convert is not a good word choice. The Datum of the parameter is stored inside a new Python object(that only holds a Datum). So more like "copied into Python memory", and associated with its respective type. Wrapped in a Python object? One cool thing about doing it this way, is that if you just pass parameters forward to a prepared statement, there's no type I/O overhead. Not a huge performance win for common cases, but if someone were passing larger arrays around, it could be quite beneficial. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 19 Nov 2009 13:21 On ons, 2009-11-18 at 12:28 -0500, Tom Lane wrote: > "Joshua D. Drake" <jd(a)commandprompt.com> writes: > > On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote: > >> Yes. That's exactly what I was complaining about upthread. I'm not > >> a Python user, but from what I can gather of the 2-to-3 changes, > >> having to choose one at package build time is going to be a disaster. > > > Agreed. We really need to have a plpython and plpython3. > > Peter was concerned about duplicative maintenance effort, but what I > think this patch shows is that (at least for the near future) both > could be built from a single source file. What we need is configure > and makefile support to do that. By the way, it occurred to me that having two different versions of libpython loaded into the same process is probably not going to work sanely. So whatever solution we come up with for the Python 3 transition, the possibilities for a jolly back-and-forth are probably going to be quite limited. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 19 Nov 2009 13:32 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 19 Nov 2009 13:43 Peter Eisentraut <peter_e(a)gmx.net> writes: > By the way, it occurred to me that having two different versions of > libpython loaded into the same process is probably not going to work > sanely. Why not? There's no way they'd even know about each other. We tell the loader not to make the symbols globally visible. But in any case, my main concern here is that I don't want to have to predetermine which python version a user of Red Hat/Fedora will have to use. If they can only use one at a time, that's still a good bit better than not having a choice at all. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: James Pye on 19 Nov 2009 15:12
On Nov 19, 2009, at 11:32 AM, Peter Eisentraut wrote: > But you wouldn't, for example, get away with breaking SQL (or even > improving it incompatibly) to facilitate a better elog. This doesn't fit the situation. I'm not breaking PL/Python. I'm trying to add PL/Python3. =) > I think of a PL/Python function as a Python script file stored > in the database. For Python, I think that's a mistake. Python scripts are independent applications. [tho, I think this does illuminate our perspectives...] -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |