[COMMITTERS] pgsql: Made code in ecpg better readable.
Made code in ecpg better readable. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/10ecc0d5867b8dd39cf506b8bb02053ede05fb60 Modified Files -- src/interfaces/ecpg/preproc/ecpg.header| 92 ++-- .../ecpg/test/expected/preproc-outofscope.c| 40 2 files changed, 67 insertions(+), 65 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make executor's SELECT INTO code save and restore original tuple
Make executor's SELECT INTO code save and restore original tuple receiver. As previously coded, the QueryDesc's dest pointer was left dangling (pointing at an already-freed receiver object) after ExecutorEnd. It's a bit astonishing that it took us this long to notice, and I'm not sure that the known problem case with SQL functions is the only one. Fix it by saving and restoring the original receiver pointer, which seems the most bulletproof way of ensuring any related bugs are also covered. Per bug #6379 from Paul Ramsey. Back-patch to 8.4 where the current handling of SELECT INTO was introduced. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/dfd26f9c5f371437f243249025863ea9911aacaa Modified Files -- src/backend/executor/execMain.c | 20 +++- src/test/regress/expected/select_into.out | 25 + src/test/regress/sql/select_into.sql | 15 +++ 3 files changed, 55 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make executor's SELECT INTO code save and restore original tuple
Make executor's SELECT INTO code save and restore original tuple receiver. As previously coded, the QueryDesc's dest pointer was left dangling (pointing at an already-freed receiver object) after ExecutorEnd. It's a bit astonishing that it took us this long to notice, and I'm not sure that the known problem case with SQL functions is the only one. Fix it by saving and restoring the original receiver pointer, which seems the most bulletproof way of ensuring any related bugs are also covered. Per bug #6379 from Paul Ramsey. Back-patch to 8.4 where the current handling of SELECT INTO was introduced. Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/658ee0108637683216fb093b9f2c7e23bfd150c5 Modified Files -- src/backend/executor/execMain.c | 20 +++- src/test/regress/expected/select_into.out | 25 + src/test/regress/sql/select_into.sql | 15 +++ 3 files changed, 55 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make executor's SELECT INTO code save and restore original tuple
Make executor's SELECT INTO code save and restore original tuple receiver. As previously coded, the QueryDesc's dest pointer was left dangling (pointing at an already-freed receiver object) after ExecutorEnd. It's a bit astonishing that it took us this long to notice, and I'm not sure that the known problem case with SQL functions is the only one. Fix it by saving and restoring the original receiver pointer, which seems the most bulletproof way of ensuring any related bugs are also covered. Per bug #6379 from Paul Ramsey. Back-patch to 8.4 where the current handling of SELECT INTO was introduced. Branch -- REL8_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/d23c38d46c78ddccd927cc4fef85e647df9c136b Modified Files -- src/backend/executor/execMain.c | 20 +++- src/test/regress/expected/select_into.out | 25 + src/test/regress/sql/select_into.sql | 14 ++ 3 files changed, 54 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make executor's SELECT INTO code save and restore original tuple
Make executor's SELECT INTO code save and restore original tuple receiver. As previously coded, the QueryDesc's dest pointer was left dangling (pointing at an already-freed receiver object) after ExecutorEnd. It's a bit astonishing that it took us this long to notice, and I'm not sure that the known problem case with SQL functions is the only one. Fix it by saving and restoring the original receiver pointer, which seems the most bulletproof way of ensuring any related bugs are also covered. Per bug #6379 from Paul Ramsey. Back-patch to 8.4 where the current handling of SELECT INTO was introduced. Branch -- REL9_0_STABLE Details --- http://git.postgresql.org/pg/commitdiff/c024a3b3be1c86459f9b47f81f61cb8a67ee2712 Modified Files -- src/backend/executor/execMain.c | 20 +++- src/test/regress/expected/select_into.out | 25 + src/test/regress/sql/select_into.sql | 14 ++ 3 files changed, 54 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
