aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/numeric.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-09-06 13:57:10 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2020-09-06 14:13:19 -0400
commit8e3c58e6e459b285d37edb6129e412ed25cd90c1 (patch)
tree853632a3efab6405a36dca91f2e69d5fe399536b /src/backend/utils/adt/numeric.c
parent68b603e1a934dcd82e259b7776565ec1776e7a29 (diff)
downloadpostgresql-8e3c58e6e459b285d37edb6129e412ed25cd90c1.tar.gz
postgresql-8e3c58e6e459b285d37edb6129e412ed25cd90c1.zip
Refactor pg_get_line() to expose an alternative StringInfo-based API.
Letting the caller provide a StringInfo to read into is helpful when the caller needs to merge lines or otherwise modify the data after it's been read. Notably, now the code added by commit 8f8154a50 can use pg_get_line_append() instead of having its own copy of that logic. A follow-on commit will also make use of this. Also, since StringInfo buffers are a minimum of 1KB long, blindly using pg_get_line() in a loop can eat a lot more memory than one would expect. I discovered for instance that commit e0f05cd5b caused initdb to consume circa 10MB to read postgres.bki, even though that's under 1MB worth of data. A less memory-hungry alternative is to re-use the same StringInfo for all lines and pg_strdup the results. Discussion: https://postgr.es/m/1315832.1599345736@sss.pgh.pa.us
Diffstat (limited to 'src/backend/utils/adt/numeric.c')
0 files changed, 0 insertions, 0 deletions