Rethink the dependencies recorded for FieldSelect/FieldStore nodes.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 27 Oct 2017 16:18:56 +0000 (12:18 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 27 Oct 2017 16:19:09 +0000 (12:19 -0400)
commit6784d7a1dc69d53b7f41eebf62bf7ffd63885294
tree025fbb92baf1c35c07c054d336a2a754e18b5d7d
parentf0392e677ed098e9e514ad5e4d5dc148c0474c63
Rethink the dependencies recorded for FieldSelect/FieldStore nodes.

On closer investigation, commits f3ea3e3e8 et al were a few bricks
shy of a load.  What we need is not so much to lock down the result
type of a FieldSelect, as to lock down the existence of the column
it's trying to extract.  Otherwise, we can break it by dropping that
column.  The dependency on the result type is then held indirectly
through the column, and doesn't need to be recorded explicitly.

Out of paranoia, I left in the code to record a dependency on the
result type, but it's used only if we can't identify the pg_class OID
for the column.  That shouldn't ever happen right now, AFAICS, but
it seems possible that in future the input node could be marked as
being of type RECORD rather than some specific composite type.

Likewise for FieldStore.

Like the previous patch, back-patch to all supported branches.

Discussion: https://postgr.es/m/22571.1509064146@sss.pgh.pa.us
src/backend/catalog/dependency.c
src/test/regress/expected/alter_table.out
src/test/regress/sql/alter_table.sql