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. > 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): ... > Also, it's inconsistent with normal Python script files Hinges on whether "normal" is actually normal. I often use the __name__ convention in script files myself: if __name__ == '__main__': main(...) That is, using that convention, the script can be import'd and used without executing the "script functionality". (It has proven to be very handy a few times now) > and with other PLs. I don't understand why that's a significant enough interest to note. > I don't need another PostgreSQL implementation on top of Python. Indeed, and I do understand that. That is, I have removed some features with that very thought in mind. (OTOH, I consider the date_part properties on datetime types to be special: too likely useful.) [tho, "PostgreSQL implementation"? I think I understand what you were getting at, but..] > The maintenance effort required to keep those two consistent aside. I don't think there are many consistency issues here. What did you have in mind? > Again, I'm only one user. But so far I haven't seen anyone else speak up > here, and clearly accepting this for inclusion will need nontrivial > convincing. Agreed. It would seem quite doomed. At this point, I'm not going to try getting it into PG. (apparent futility and such) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
