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
benefitsof a *natural* initialization section (the module body) was enough to convince me. The added value on the PL
developer'sside 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
providesproperties 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
nodirect utility as they will likely need to convert anyways. (If that's your common use-case, then the absence of
interestin 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.