On 3/22/17 11:46, Andrew Dunstan wrote:
> This is a very simple patch that does what it advertises. It applies
> cleanly and provides tests for both the new methods (plan.cursor and
> plan.execute).
>
> Marking Ready For Committer.
committed
--
Peter Eisentraut
Jim Nasby writes:
> On 2/25/17 10:27 AM, Peter Eisentraut wrote:
>> So I'm also wondering here which style people prefer so
>> I can implement it there.
>
> I think the more OO style is definitely better. I expect it would
> simplify the code as well.
I'm not a Python person,
On 2/25/17 10:27 AM, Peter Eisentraut wrote:
So I'm also wondering here which style people prefer so
I can implement it there.
I think the more OO style is definitely better. I expect it would
simplify the code as well.
--
Jim C. Nasby, Data Architect j...@nasby.net
On 03/21/2017 06:27 PM, Andrew Dunstan wrote:
> On 03/16/2017 05:32 PM, David Steele wrote:
>> On 2/25/17 1:27 PM, Peter Eisentraut wrote:
>>> Something that has been bothering me in PL/Python for a long time is the
>>> non-object-oriented way in which plans are prepared and executed:
>>>
>>>
On 03/16/2017 05:32 PM, David Steele wrote:
> On 2/25/17 1:27 PM, Peter Eisentraut wrote:
>> Something that has been bothering me in PL/Python for a long time is the
>> non-object-oriented way in which plans are prepared and executed:
>>
>> plan = plpy.prepare(...)
>> res =
On 2/25/17 1:27 PM, Peter Eisentraut wrote:
> Something that has been bothering me in PL/Python for a long time is the
> non-object-oriented way in which plans are prepared and executed:
>
> plan = plpy.prepare(...)
> res = plpy.execute(plan, ...)
>
> where plpy.execute() takes either a
Something that has been bothering me in PL/Python for a long time is the
non-object-oriented way in which plans are prepared and executed:
plan = plpy.prepare(...)
res = plpy.execute(plan, ...)
where plpy.execute() takes either a plan or a query string.
I think a better style would be