pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Make plperl's handling of Perl arrays safer and more consistent. 7+ messages / 1 participants [nested] [flat]
* pgsql: Make plperl's handling of Perl arrays safer and more consistent. @ 2026-08-17 19:06 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-08-17 19:06 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make plperl's handling of Perl arrays safer and more consistent. plperl_func_handler()'s stanza for handling an arrayref result in a SETOF function could loop forever (or at least till OOM) when given a tied array, since av_fetch won't necessarily ever return a null pointer in that case. Be consistent with the other places where we traverse a perl array: call av_len() once and use len+1 as the loop limit, silently ignoring any null pointers we get back from that range of subscripts. But actually, Perl's preferred locution for this seems to be to use av_count() not av_len()+1. av_count() seems better since there's less risk of forgetting to add 1. Also, both of those functions return Size_t (or SSize_t) not int, creating at least a theoretical overflow hazard. While we're modernizing this, let's use the correct variable type where we can, and include an overflow check where we can't. Reported-by: Claude Code (via Noah Misch) Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Rachitskiy <pl0h0yp1@gmail.com> Discussion: https://postgr.es/m/569769.1786901901@sss.pgh.pa.us Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/131444cd167afd135768b5d1605caf89fb25e4e2 Modified Files -------------- contrib/jsonb_plperl/jsonb_plperl.c | 5 ++--- src/pl/plperl/plperl.c | 41 ++++++++++++++++++++++++++++--------- 2 files changed, 33 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Make plperl's handling of Perl arrays safer and more consistent. @ 2026-08-17 19:06 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-08-17 19:06 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make plperl's handling of Perl arrays safer and more consistent. plperl_func_handler()'s stanza for handling an arrayref result in a SETOF function could loop forever (or at least till OOM) when given a tied array, since av_fetch won't necessarily ever return a null pointer in that case. Be consistent with the other places where we traverse a perl array: call av_len() once and use len+1 as the loop limit, silently ignoring any null pointers we get back from that range of subscripts. But actually, Perl's preferred locution for this seems to be to use av_count() not av_len()+1. av_count() seems better since there's less risk of forgetting to add 1. Also, both of those functions return Size_t (or SSize_t) not int, creating at least a theoretical overflow hazard. While we're modernizing this, let's use the correct variable type where we can, and include an overflow check where we can't. Reported-by: Claude Code (via Noah Misch) Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Rachitskiy <pl0h0yp1@gmail.com> Discussion: https://postgr.es/m/569769.1786901901@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b6b4f5a6460a6c2634924dd44e0b07f990b8aae0 Modified Files -------------- contrib/jsonb_plperl/jsonb_plperl.c | 5 ++--- src/pl/plperl/plperl.c | 41 ++++++++++++++++++++++++++++--------- 2 files changed, 33 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Make plperl's handling of Perl arrays safer and more consistent. @ 2026-08-17 19:06 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-08-17 19:06 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make plperl's handling of Perl arrays safer and more consistent. plperl_func_handler()'s stanza for handling an arrayref result in a SETOF function could loop forever (or at least till OOM) when given a tied array, since av_fetch won't necessarily ever return a null pointer in that case. Be consistent with the other places where we traverse a perl array: call av_len() once and use len+1 as the loop limit, silently ignoring any null pointers we get back from that range of subscripts. But actually, Perl's preferred locution for this seems to be to use av_count() not av_len()+1. av_count() seems better since there's less risk of forgetting to add 1. Also, both of those functions return Size_t (or SSize_t) not int, creating at least a theoretical overflow hazard. While we're modernizing this, let's use the correct variable type where we can, and include an overflow check where we can't. Reported-by: Claude Code (via Noah Misch) Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Rachitskiy <pl0h0yp1@gmail.com> Discussion: https://postgr.es/m/569769.1786901901@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/af659efcb3a15dad690e9c9666ed82ed350e5522 Modified Files -------------- contrib/jsonb_plperl/jsonb_plperl.c | 5 ++--- src/pl/plperl/plperl.c | 41 ++++++++++++++++++++++++++++--------- 2 files changed, 33 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Make plperl's handling of Perl arrays safer and more consistent. @ 2026-08-17 19:06 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-08-17 19:06 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make plperl's handling of Perl arrays safer and more consistent. plperl_func_handler()'s stanza for handling an arrayref result in a SETOF function could loop forever (or at least till OOM) when given a tied array, since av_fetch won't necessarily ever return a null pointer in that case. Be consistent with the other places where we traverse a perl array: call av_len() once and use len+1 as the loop limit, silently ignoring any null pointers we get back from that range of subscripts. But actually, Perl's preferred locution for this seems to be to use av_count() not av_len()+1. av_count() seems better since there's less risk of forgetting to add 1. Also, both of those functions return Size_t (or SSize_t) not int, creating at least a theoretical overflow hazard. While we're modernizing this, let's use the correct variable type where we can, and include an overflow check where we can't. Reported-by: Claude Code (via Noah Misch) Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Rachitskiy <pl0h0yp1@gmail.com> Discussion: https://postgr.es/m/569769.1786901901@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3c4d77480cfc0235f313f7ac9085bdcf698dac6e Modified Files -------------- contrib/jsonb_plperl/jsonb_plperl.c | 5 ++--- src/pl/plperl/plperl.c | 41 ++++++++++++++++++++++++++++--------- 2 files changed, 33 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Make plperl's handling of Perl arrays safer and more consistent. @ 2026-08-17 19:06 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-08-17 19:06 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make plperl's handling of Perl arrays safer and more consistent. plperl_func_handler()'s stanza for handling an arrayref result in a SETOF function could loop forever (or at least till OOM) when given a tied array, since av_fetch won't necessarily ever return a null pointer in that case. Be consistent with the other places where we traverse a perl array: call av_len() once and use len+1 as the loop limit, silently ignoring any null pointers we get back from that range of subscripts. But actually, Perl's preferred locution for this seems to be to use av_count() not av_len()+1. av_count() seems better since there's less risk of forgetting to add 1. Also, both of those functions return Size_t (or SSize_t) not int, creating at least a theoretical overflow hazard. While we're modernizing this, let's use the correct variable type where we can, and include an overflow check where we can't. Reported-by: Claude Code (via Noah Misch) Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Rachitskiy <pl0h0yp1@gmail.com> Discussion: https://postgr.es/m/569769.1786901901@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/794473ec222f937db15a4a419000d6278d97421b Modified Files -------------- contrib/jsonb_plperl/jsonb_plperl.c | 5 ++--- src/pl/plperl/plperl.c | 41 ++++++++++++++++++++++++++++--------- 2 files changed, 33 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Make plperl's handling of Perl arrays safer and more consistent. @ 2026-08-17 19:06 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-08-17 19:06 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make plperl's handling of Perl arrays safer and more consistent. plperl_func_handler()'s stanza for handling an arrayref result in a SETOF function could loop forever (or at least till OOM) when given a tied array, since av_fetch won't necessarily ever return a null pointer in that case. Be consistent with the other places where we traverse a perl array: call av_len() once and use len+1 as the loop limit, silently ignoring any null pointers we get back from that range of subscripts. But actually, Perl's preferred locution for this seems to be to use av_count() not av_len()+1. av_count() seems better since there's less risk of forgetting to add 1. Also, both of those functions return Size_t (or SSize_t) not int, creating at least a theoretical overflow hazard. While we're modernizing this, let's use the correct variable type where we can, and include an overflow check where we can't. Reported-by: Claude Code (via Noah Misch) Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Rachitskiy <pl0h0yp1@gmail.com> Discussion: https://postgr.es/m/569769.1786901901@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1035eab491bf86db9bbb754854ba3d02ac80f4c4 Modified Files -------------- contrib/jsonb_plperl/jsonb_plperl.c | 5 ++--- src/pl/plperl/plperl.c | 41 ++++++++++++++++++++++++++++--------- 2 files changed, 33 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Make plperl's handling of Perl arrays safer and more consistent. @ 2026-08-17 19:06 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-08-17 19:06 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make plperl's handling of Perl arrays safer and more consistent. plperl_func_handler()'s stanza for handling an arrayref result in a SETOF function could loop forever (or at least till OOM) when given a tied array, since av_fetch won't necessarily ever return a null pointer in that case. Be consistent with the other places where we traverse a perl array: call av_len() once and use len+1 as the loop limit, silently ignoring any null pointers we get back from that range of subscripts. But actually, Perl's preferred locution for this seems to be to use av_count() not av_len()+1. av_count() seems better since there's less risk of forgetting to add 1. Also, both of those functions return Size_t (or SSize_t) not int, creating at least a theoretical overflow hazard. While we're modernizing this, let's use the correct variable type where we can, and include an overflow check where we can't. Reported-by: Claude Code (via Noah Misch) Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andrey Rachitskiy <pl0h0yp1@gmail.com> Discussion: https://postgr.es/m/569769.1786901901@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ede3188e118f81ea933ac5d64866190024f678a7 Modified Files -------------- contrib/jsonb_plperl/jsonb_plperl.c | 5 ++--- src/pl/plperl/plperl.c | 41 ++++++++++++++++++++++++++++--------- 2 files changed, 33 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-08-17 19:06 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-08-17 19:06 pgsql: Make plperl's handling of Perl arrays safer and more consistent. Tom Lane <tgl@sss.pgh.pa.us> 2026-08-17 19:06 pgsql: Make plperl's handling of Perl arrays safer and more consistent. Tom Lane <tgl@sss.pgh.pa.us> 2026-08-17 19:06 pgsql: Make plperl's handling of Perl arrays safer and more consistent. Tom Lane <tgl@sss.pgh.pa.us> 2026-08-17 19:06 pgsql: Make plperl's handling of Perl arrays safer and more consistent. Tom Lane <tgl@sss.pgh.pa.us> 2026-08-17 19:06 pgsql: Make plperl's handling of Perl arrays safer and more consistent. Tom Lane <tgl@sss.pgh.pa.us> 2026-08-17 19:06 pgsql: Make plperl's handling of Perl arrays safer and more consistent. Tom Lane <tgl@sss.pgh.pa.us> 2026-08-17 19:06 pgsql: Make plperl's handling of Perl arrays safer and more consistent. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox