pgsql: Fix misidentification of SQL statement type in plpgsql's exec_st

[Tom Lane]

Fix misidentification of SQL statement type in plpgsql's exec_stmt_execsql.

To distinguish SQL statements that are INSERT/UPDATE/DELETE from other
ones, exec_stmt_execsql looked at the post-rewrite form of the statement
rather than the original.  This is problematic because it did that only
during first execution of the statement (in a session), but the correct
answer could change later due to addition or removal of DO INSTEAD rules
during the session.  That could lead to an Assert failure, as reported
by Tushar Ahuja and Robert Haas.  In non-assert builds, there's a hazard
that we would fail to enforce STRICT behavior when we'd be expected to.
That would happen if an initially present DO INSTEAD, that replaced the
original statement with one of a different type, were removed; after that
the statement should act "normally", including strictness enforcement, but
it didn't.  (The converse case of enforcing strictness when we shouldn't
doesn't seem to be a hazard, as addition of a DO INSTEAD that changes the
statement type would always lead to acting as though the statement returned
zero rows, so that the strictness error could not fire.)

To fix, inspect the original form of the statement not the post-rewrite
form, making it valid to assume the answer can't change intra-session.
This should lead to the same answer in every case except when there is a
DO INSTEAD that changes the statement type; we will now set mod_stmt=true
anyway, while we would not have done so before.  That breaks the Assert
in the SPI_OK_REWRITTEN code path, which expected the latter behavior.
It might be all right to assert mod_stmt rather than !mod_stmt there,
but I'm not entirely convinced that that'd always hold, so just remove
the assertion altogether.

This has been broken for a long time, so back-patch to all supported
branches.

Discussion: 
https://postgr.es/m/ca+tgmozurrn4xvze_bbbn_xp0bdwumeue-0oyf0fjpfvu2y...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/9a8aa25ccc6c285cd4f02afe4718eafd20dc34c5

Modified Files
--
src/pl/plpgsql/src/pl_exec.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)

pgsql: Fix misidentification of SQL statement type in plpgsql's exec_st

[Tom Lane]

Fix misidentification of SQL statement type in plpgsql's exec_stmt_execsql.

To distinguish SQL statements that are INSERT/UPDATE/DELETE from other
ones, exec_stmt_execsql looked at the post-rewrite form of the statement
rather than the original.  This is problematic because it did that only
during first execution of the statement (in a session), but the correct
answer could change later due to addition or removal of DO INSTEAD rules
during the session.  That could lead to an Assert failure, as reported
by Tushar Ahuja and Robert Haas.  In non-assert builds, there's a hazard
that we would fail to enforce STRICT behavior when we'd be expected to.
That would happen if an initially present DO INSTEAD, that replaced the
original statement with one of a different type, were removed; after that
the statement should act "normally", including strictness enforcement, but
it didn't.  (The converse case of enforcing strictness when we shouldn't
doesn't seem to be a hazard, as addition of a DO INSTEAD that changes the
statement type would always lead to acting as though the statement returned
zero rows, so that the strictness error could not fire.)

To fix, inspect the original form of the statement not the post-rewrite
form, making it valid to assume the answer can't change intra-session.
This should lead to the same answer in every case except when there is a
DO INSTEAD that changes the statement type; we will now set mod_stmt=true
anyway, while we would not have done so before.  That breaks the Assert
in the SPI_OK_REWRITTEN code path, which expected the latter behavior.
It might be all right to assert mod_stmt rather than !mod_stmt there,
but I'm not entirely convinced that that'd always hold, so just remove
the assertion altogether.

This has been broken for a long time, so back-patch to all supported
branches.

Discussion: 
https://postgr.es/m/ca+tgmozurrn4xvze_bbbn_xp0bdwumeue-0oyf0fjpfvu2y...@mail.gmail.com

Branch
--
REL9_5_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/004293c666516065033c8eeb5f1d363c0a9542dd

Modified Files
--
src/pl/plpgsql/src/pl_exec.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)

pgsql: Fix misidentification of SQL statement type in plpgsql's exec_st

[Tom Lane]

Fix misidentification of SQL statement type in plpgsql's exec_stmt_execsql.

To distinguish SQL statements that are INSERT/UPDATE/DELETE from other
ones, exec_stmt_execsql looked at the post-rewrite form of the statement
rather than the original.  This is problematic because it did that only
during first execution of the statement (in a session), but the correct
answer could change later due to addition or removal of DO INSTEAD rules
during the session.  That could lead to an Assert failure, as reported
by Tushar Ahuja and Robert Haas.  In non-assert builds, there's a hazard
that we would fail to enforce STRICT behavior when we'd be expected to.
That would happen if an initially present DO INSTEAD, that replaced the
original statement with one of a different type, were removed; after that
the statement should act "normally", including strictness enforcement, but
it didn't.  (The converse case of enforcing strictness when we shouldn't
doesn't seem to be a hazard, as addition of a DO INSTEAD that changes the
statement type would always lead to acting as though the statement returned
zero rows, so that the strictness error could not fire.)

To fix, inspect the original form of the statement not the post-rewrite
form, making it valid to assume the answer can't change intra-session.
This should lead to the same answer in every case except when there is a
DO INSTEAD that changes the statement type; we will now set mod_stmt=true
anyway, while we would not have done so before.  That breaks the Assert
in the SPI_OK_REWRITTEN code path, which expected the latter behavior.
It might be all right to assert mod_stmt rather than !mod_stmt there,
but I'm not entirely convinced that that'd always hold, so just remove
the assertion altogether.

This has been broken for a long time, so back-patch to all supported
branches.

Discussion: 
https://postgr.es/m/ca+tgmozurrn4xvze_bbbn_xp0bdwumeue-0oyf0fjpfvu2y...@mail.gmail.com

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/f9ecb6caba071304a8a5c502b78ffd3b06f0bb1c

Modified Files
--
src/pl/plpgsql/src/pl_exec.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)

pgsql: Fix misidentification of SQL statement type in plpgsql's exec_st

[Tom Lane]

Fix misidentification of SQL statement type in plpgsql's exec_stmt_execsql.

To distinguish SQL statements that are INSERT/UPDATE/DELETE from other
ones, exec_stmt_execsql looked at the post-rewrite form of the statement
rather than the original.  This is problematic because it did that only
during first execution of the statement (in a session), but the correct
answer could change later due to addition or removal of DO INSTEAD rules
during the session.  That could lead to an Assert failure, as reported
by Tushar Ahuja and Robert Haas.  In non-assert builds, there's a hazard
that we would fail to enforce STRICT behavior when we'd be expected to.
That would happen if an initially present DO INSTEAD, that replaced the
original statement with one of a different type, were removed; after that
the statement should act "normally", including strictness enforcement, but
it didn't.  (The converse case of enforcing strictness when we shouldn't
doesn't seem to be a hazard, as addition of a DO INSTEAD that changes the
statement type would always lead to acting as though the statement returned
zero rows, so that the strictness error could not fire.)

To fix, inspect the original form of the statement not the post-rewrite
form, making it valid to assume the answer can't change intra-session.
This should lead to the same answer in every case except when there is a
DO INSTEAD that changes the statement type; we will now set mod_stmt=true
anyway, while we would not have done so before.  That breaks the Assert
in the SPI_OK_REWRITTEN code path, which expected the latter behavior.
It might be all right to assert mod_stmt rather than !mod_stmt there,
but I'm not entirely convinced that that'd always hold, so just remove
the assertion altogether.

This has been broken for a long time, so back-patch to all supported
branches.

Discussion: 
https://postgr.es/m/ca+tgmozurrn4xvze_bbbn_xp0bdwumeue-0oyf0fjpfvu2y...@mail.gmail.com

Branch
--
REL9_4_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/98d522a1de1b6c90edabbbfda0cda734286edd03

Modified Files
--
src/pl/plpgsql/src/pl_exec.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)

pgsql: Fix misidentification of SQL statement type in plpgsql's exec_st

[Tom Lane]

Fix misidentification of SQL statement type in plpgsql's exec_stmt_execsql.

To distinguish SQL statements that are INSERT/UPDATE/DELETE from other
ones, exec_stmt_execsql looked at the post-rewrite form of the statement
rather than the original.  This is problematic because it did that only
during first execution of the statement (in a session), but the correct
answer could change later due to addition or removal of DO INSTEAD rules
during the session.  That could lead to an Assert failure, as reported
by Tushar Ahuja and Robert Haas.  In non-assert builds, there's a hazard
that we would fail to enforce STRICT behavior when we'd be expected to.
That would happen if an initially present DO INSTEAD, that replaced the
original statement with one of a different type, were removed; after that
the statement should act "normally", including strictness enforcement, but
it didn't.  (The converse case of enforcing strictness when we shouldn't
doesn't seem to be a hazard, as addition of a DO INSTEAD that changes the
statement type would always lead to acting as though the statement returned
zero rows, so that the strictness error could not fire.)

To fix, inspect the original form of the statement not the post-rewrite
form, making it valid to assume the answer can't change intra-session.
This should lead to the same answer in every case except when there is a
DO INSTEAD that changes the statement type; we will now set mod_stmt=true
anyway, while we would not have done so before.  That breaks the Assert
in the SPI_OK_REWRITTEN code path, which expected the latter behavior.
It might be all right to assert mod_stmt rather than !mod_stmt there,
but I'm not entirely convinced that that'd always hold, so just remove
the assertion altogether.

This has been broken for a long time, so back-patch to all supported
branches.

Discussion: 
https://postgr.es/m/ca+tgmozurrn4xvze_bbbn_xp0bdwumeue-0oyf0fjpfvu2y...@mail.gmail.com

Branch
--
REL9_3_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/da757bf0ffb05ed3c18276bd1d4cdf1d2150de18

Modified Files
--
src/pl/plpgsql/src/pl_exec.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)

pgsql: Fix misidentification of SQL statement type in plpgsql's exec_st

[Tom Lane]

Fix misidentification of SQL statement type in plpgsql's exec_stmt_execsql.

To distinguish SQL statements that are INSERT/UPDATE/DELETE from other
ones, exec_stmt_execsql looked at the post-rewrite form of the statement
rather than the original.  This is problematic because it did that only
during first execution of the statement (in a session), but the correct
answer could change later due to addition or removal of DO INSTEAD rules
during the session.  That could lead to an Assert failure, as reported
by Tushar Ahuja and Robert Haas.  In non-assert builds, there's a hazard
that we would fail to enforce STRICT behavior when we'd be expected to.
That would happen if an initially present DO INSTEAD, that replaced the
original statement with one of a different type, were removed; after that
the statement should act "normally", including strictness enforcement, but
it didn't.  (The converse case of enforcing strictness when we shouldn't
doesn't seem to be a hazard, as addition of a DO INSTEAD that changes the
statement type would always lead to acting as though the statement returned
zero rows, so that the strictness error could not fire.)

To fix, inspect the original form of the statement not the post-rewrite
form, making it valid to assume the answer can't change intra-session.
This should lead to the same answer in every case except when there is a
DO INSTEAD that changes the statement type; we will now set mod_stmt=true
anyway, while we would not have done so before.  That breaks the Assert
in the SPI_OK_REWRITTEN code path, which expected the latter behavior.
It might be all right to assert mod_stmt rather than !mod_stmt there,
but I'm not entirely convinced that that'd always hold, so just remove
the assertion altogether.

This has been broken for a long time, so back-patch to all supported
branches.

Discussion: 
https://postgr.es/m/ca+tgmozurrn4xvze_bbbn_xp0bdwumeue-0oyf0fjpfvu2y...@mail.gmail.com

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/5a225b0d61778c1912e766a8ea0b60216734b1d2

Modified Files
--
src/pl/plpgsql/src/pl_exec.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)

pgsql: Remove incorrect statement about IPC configuration on OpenBSD

[Magnus Hagander]

Remove incorrect statement about IPC configuration on OpenBSD

kern.ipc.shm_use_phys is not a sysctl on OpenBSD, and SEMMAP is not
a kernel configuration option. These were probably copy pasteos from
when the documentation had a single paragraph for *BSD.

Author: Daniel Gustafsson 

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/de1593d45587988f6e2450e78d623718df3e085e

Modified Files
--
doc/src/sgml/runtime.sgml | 7 ---
1 file changed, 7 deletions(-)

pgsql: Remove incorrect statement about IPC configuration on OpenBSD

[Magnus Hagander]

Remove incorrect statement about IPC configuration on OpenBSD

kern.ipc.shm_use_phys is not a sysctl on OpenBSD, and SEMMAP is not
a kernel configuration option. These were probably copy pasteos from
when the documentation had a single paragraph for *BSD.

Author: Daniel Gustafsson 

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/7019c21c1bf51eafb56595b916c216ca860ad499

Modified Files
--
doc/src/sgml/runtime.sgml | 7 ---
1 file changed, 7 deletions(-)

pgsql: Remove incorrect statement about IPC configuration on OpenBSD

[Magnus Hagander]

Remove incorrect statement about IPC configuration on OpenBSD

kern.ipc.shm_use_phys is not a sysctl on OpenBSD, and SEMMAP is not
a kernel configuration option. These were probably copy pasteos from
when the documentation had a single paragraph for *BSD.

Author: Daniel Gustafsson 

Branch
--
REL9_3_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/60242ebcfeae015462d5539d41c12b40fcad3045

Modified Files
--
doc/src/sgml/runtime.sgml | 7 ---
1 file changed, 7 deletions(-)

pgsql: Remove incorrect statement about IPC configuration on OpenBSD

[Magnus Hagander]

Remove incorrect statement about IPC configuration on OpenBSD

kern.ipc.shm_use_phys is not a sysctl on OpenBSD, and SEMMAP is not
a kernel configuration option. These were probably copy pasteos from
when the documentation had a single paragraph for *BSD.

Author: Daniel Gustafsson 

Branch
--
REL9_5_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/5671e28586753c1618bb279d39ace7b55258b2ec

Modified Files
--
doc/src/sgml/runtime.sgml | 7 ---
1 file changed, 7 deletions(-)