aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/jsonfuncs.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2017-10-27 12:18:57 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2017-10-27 12:18:57 -0400
commit376ac922df7815bc88709090e3b70b7752e9a327 (patch)
treed76af9fbd4d2bba4fb0cdfcf5dbddd744ce73bb2 /src/backend/utils/adt/jsonfuncs.c
parent55429227ce20bf7285b027370a04dab530beb762 (diff)
downloadpostgresql-376ac922df7815bc88709090e3b70b7752e9a327.tar.gz
postgresql-376ac922df7815bc88709090e3b70b7752e9a327.zip
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
Diffstat (limited to 'src/backend/utils/adt/jsonfuncs.c')
0 files changed, 0 insertions, 0 deletions