aboutsummaryrefslogtreecommitdiff
path: root/src/backend/parser/parse_utilcmd.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-03-08 18:21:51 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2021-03-08 18:21:51 -0500
commit37228ecde1f061ce47a2f60fcaa0f64a93af4ea8 (patch)
tree85dc622c99f86f32f3b90e6d3845f70d47db8e5f /src/backend/parser/parse_utilcmd.c
parent90c737669fd2ab8e02ef7e8200adbce6fccf5c65 (diff)
downloadpostgresql-37228ecde1f061ce47a2f60fcaa0f64a93af4ea8.tar.gz
postgresql-37228ecde1f061ce47a2f60fcaa0f64a93af4ea8.zip
Validate the OID argument of pg_import_system_collations().
"SELECT pg_import_system_collations(0)" caused an assertion failure. With a random nonzero argument --- or indeed with zero, in non-assert builds --- it would happily make pg_collation entries with garbage values of collnamespace. These are harmless as far as I can tell (unless maybe the OID happens to become used for a schema, later on?). In any case this isn't a security issue, since the function is superuser-only. But it seems like a gotcha for unwary DBAs, so let's add a check that the given OID belongs to some schema. Back-patch to v10 where this function was introduced.
Diffstat (limited to 'src/backend/parser/parse_utilcmd.c')
0 files changed, 0 insertions, 0 deletions