Thread: [HACKERS] PL/Python: Add cursor and execute methods to plan object
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
plan = plpy.prepare(...)
res = plan.execute(...)
so that the "plan" is more like a statement handle that one finds in
other APIs.
This ended up being very easy to implement, so I'm proposing to allow
this new syntax as an alternative.
I came across this again as I was developing the background sessions API
for PL/Python. So I'm also wondering here which style people prefer so
I can implement it there.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
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 plan or a query string. > > I think a better style would be > > plan = plpy.prepare(...) > res = plan.execute(...) > > so that the "plan" is more like a statement handle that one finds in > other APIs. > > This ended up being very easy to implement, so I'm proposing to allow > this new syntax as an alternative. > > I came across this again as I was developing the background sessions API > for PL/Python. So I'm also wondering here which style people prefer so > I can implement it there. This patch applies cleanly at cccbdde. Any Python folks out there who would like to take a crack at reviewing this? -- -David david@pgmasters.net
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 = plpy.execute(plan, ...) >> >> where plpy.execute() takes either a plan or a query string. >> >> I think a better style would be >> >> plan = plpy.prepare(...) >> res = plan.execute(...) >> >> so that the "plan" is more like a statement handle that one finds in >> other APIs. >> >> This ended up being very easy to implement, so I'm proposing to allow >> this new syntax as an alternative. >> >> I came across this again as I was developing the background sessions API >> for PL/Python. So I'm also wondering here which style people prefer so >> I can implement it there. > This patch applies cleanly at cccbdde. > > Any Python folks out there who would like to take a crack at reviewing this? > > I'm not particularly a Python folk, but I've done enough over the years with PLs, including PLPython, that I think I can review this :-) cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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: >>> >>> 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 >>> >>> plan = plpy.prepare(...) >>> res = plan.execute(...) >>> >>> so that the "plan" is more like a statement handle that one finds in >>> other APIs. >>> >>> This ended up being very easy to implement, so I'm proposing to allow >>> this new syntax as an alternative. >>> >>> I came across this again as I was developing the background sessions API >>> for PL/Python. So I'm also wondering here which style people prefer so >>> I can implement it there. >> This patch applies cleanly at cccbdde. >> >> Any Python folks out there who would like to take a crack at reviewing this? >> >> > I'm not particularly a Python folk, but I've done enough over the years > with PLs, including PLPython, that I think I can review this :-) > 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. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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 jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
Re: PL/Python: Add cursor and execute methods to plan object
From
ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Date:
Jim Nasby <jim@nasby.net> 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, but I'd argue that the "more OO" style should be the primary style documented, and the old style should just be mentioned for reference. - ilmari -- - Twitter seems more influential [than blogs] in the 'gets reported in the mainstream press' sense at least. - Matt McLeod - That'd be because the content of a tweet is easier to condense down to a mainstream media article. - Calle Dybedahl
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 http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services