PL/Python: Add cursor and execute methods to plan object
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t36123psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 08:08 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t36123_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t36123_1 && git checkout t36123_1Patchset v1 (message #1) is on t36123_1
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
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers