mirror of
https://github.com/postgres/postgres.git
synced 2025-11-13 00:03:54 -05:00
30168be8f7
In the wake of 84f5c2908, it's no longer necessary for plpgsql to handle SET/RESET specially. The point of that was just to avoid taking a new transaction snapshot prematurely, which the regular code path through _SPI_execute_plan() now does just fine (in fact better, since it now does the right thing for LOCK too). Hence, rip out a few lines of code, going back to the old way of treating SET/RESET as a generic SQL command. This essentially reverts all but the test cases from b981275b6. Discussion: https://postgr.es/m/15990-eee2ac466b11293d@postgresql.org