mirror of
https://git.postgresql.org/git/postgresql.git
synced 2026-02-22 06:17:00 +08:00
ed4653db8c
Previously, rewriteTargetListIU() generated a list of attribute numbers from the targetlist, which were passed to rewriteValuesRTE(), which expected them to contain the same number of entries as there are columns in the VALUES RTE, and to be in the same order. That was fine when the target relation was a table, but for an updatable view it could be broken in at least three different ways --- rewriteTargetListIU() could insert additional targetlist entries for view columns with defaults, the view columns could be in a different order from the columns of the underlying base relation, and targetlist entries could be merged together when assigning to elements of an array or composite type. As a result, when recursing to the base relation, the list of attribute numbers generated from the rewritten targetlist could no longer be relied upon to match the columns of the VALUES RTE. We got away with that prior to 41531e42d3 because it used to always be the case that rewriteValuesRTE() did nothing for the underlying base relation, since all DEFAULTS had already been replaced when it was initially invoked for the view, but that was incorrect because it failed to apply defaults from the base relation. Fix this by examining the targetlist entries more carefully and picking out just those that are simple Vars referencing the VALUES RTE. That's sufficient for the purposes of rewriteValuesRTE(), which is only responsible for dealing with DEFAULT items in the VALUES RTE. Any DEFAULT item in the VALUES RTE that doesn't have a matching simple-Var-assignment in the targetlist is an error which we complain about, but in theory that ought to be impossible. Additionally, move this code into rewriteValuesRTE() to give a clearer separation of concerns between the 2 functions. There is no need for rewriteTargetListIU() to know about the details of the VALUES RTE. While at it, fix the comment for rewriteValuesRTE() which claimed that it doesn't support array element and field assignments --- that hasn't been true since a3c7a993d5 (9.6 and later). Back-patch to all supported versions, with minor differences for the pre-9.6 branches, which don't support array element and field assignments to the same column in multi-row VALUES lists. Reviewed by Amit Langote. Discussion: https://postgr.es/m/15623-5d67a46788ec8b7f@postgresql.org
PostgreSQL tests ================ This directory contains a variety of test infrastructure as well as some of the tests in PostgreSQL. Not all tests are here -- in particular, there are more in individual contrib/ modules and in src/bin. Not all these tests get run by "make check". Check src/test/Makefile to see which tests get run automatically. authentication/ Tests for authentication examples/ Demonstration programs for libpq that double as regression tests via "make check" isolation/ Tests for concurrent behavior at the SQL level locale/ Sanity checks for locale data, encodings, etc mb/ Tests for multibyte encoding (UTF-8) support modules/ Extensions used only or mainly for test purposes, generally not suitable for installing in production databases perl/ Infrastructure for Perl-based TAP tests recovery/ Test suite for recovery and replication regress/ PostgreSQL's main regression test suite, pg_regress ssl/ Tests to exercise and verify SSL certificate handling subscription/ Tests for logical replication thread/ A thread-safety-testing utility used by configure