On sön, 2009-11-15 at 18:39 -0700, James Pye wrote: > 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...
The question is whether it helps the user, not the implementer. As far as I can tell, it just creates more typing for no benefit whatsoever. Also, it's inconsistent with normal Python script files and with other PLs. > 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.) Right, if I use PL/Python, I do it because I want to use Python. I don't need another PostgreSQL implementation on top of Python. The maintenance effort required to keep those two consistent aside. 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. > > the pain of dealing with a second implementation. > > What pain are you anticipating? Maintenance? Right. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
