aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gist.c
diff options
context:
space:
mode:
authorStephen Frost <sfrost@snowman.net>2014-09-12 11:24:09 -0400
committerStephen Frost <sfrost@snowman.net>2014-09-12 11:24:36 -0400
commit4d96e93cb4dbd18732001a98b8d1c6a8b1be0503 (patch)
treec769b2ae200b70de55907f6f7c8f7ea4b298dc61 /src/backend/access/gist/gist.c
parentcf5c20b063fc362792be4202990e81928dbb68a1 (diff)
downloadpostgresql-4d96e93cb4dbd18732001a98b8d1c6a8b1be0503.tar.gz
postgresql-4d96e93cb4dbd18732001a98b8d1c6a8b1be0503.zip
Handle border = 3 in expanded mode
In psql, expanded mode was not being displayed correctly when using the normal ascii or unicode linestyles and border set to '3'. Now, per the documentation, border '3' is really only sensible for HTML and LaTeX formats, however, that's no excuse for ascii/unicode to break in that case, and provisions had been made for psql to cleanly handle this case (and it did, in non-expanded mode). This was broken when ascii/unicode was initially added a good five years ago because print_aligned_vertical_line wasn't passed in the border setting being used by print_aligned_vertical but instead was given the whole printTableContent. There really isn't a good reason for vertical_line to have the entire printTableContent structure, so just pass in the printTextFormat and border setting (similar to how this is handled in horizontal_line). Pointed out by Pavel Stehule, fix by me. Back-patch to all currently-supported versions.
Diffstat (limited to 'src/backend/access/gist/gist.c')
0 files changed, 0 insertions, 0 deletions