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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
