aboutsummaryrefslogtreecommitdiff
path: root/src/backend/tcop/postgres.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-08-07 13:13:42 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2018-08-07 13:13:42 -0400
commitf3f6558b5d767317baad6934c6bd0def3bd601bd (patch)
tree7156adf80d4dfc1bc142d9f6c9624ae89feae3de /src/backend/tcop/postgres.c
parent2a37ee373aad7f8a702601b1c0bc0df6c79cff58 (diff)
downloadpostgresql-f3f6558b5d767317baad6934c6bd0def3bd601bd.tar.gz
postgresql-f3f6558b5d767317baad6934c6bd0def3bd601bd.zip
Ensure pg_dump_sort.c sorts null vs non-null namespace consistently.
The original coding here (which is, I believe, my fault) supposed that it didn't need to concern itself with the possibility that one object of a given type-priority has a namespace while another doesn't. But that's not reliably true anymore, if it ever was; and if it does happen then it's possible that DOTypeNameCompare returns self-inconsistent comparison results. That leads to unspecified behavior in qsort() and a resultant weird output order from pg_dump. This should end up being only a cosmetic problem, because any ordering constraints that actually matter should be enforced by the later dependency-based sort. Still, it's a bug, so back-patch. Report and fix by Jacob Champion, though I editorialized on his patch to the extent of making NULL sort after non-NULL, for consistency with our usual sorting definitions. Discussion: https://postgr.es/m/CABAq_6Hw+V-Kj7PNfD5tgOaWT_-qaYkc+SRmJkPLeUjYXLdxwQ@mail.gmail.com
Diffstat (limited to 'src/backend/tcop/postgres.c')
0 files changed, 0 insertions, 0 deletions