Daniel Gustafsson <dan...@yesql.se> writes:
> The pg_service.conf parsing thread [0] made me realize that we have a
> hardwired
> line length of max 256 bytes. Lifting this would be in line with recent work
> for ecpg, pg_regress and pg_hba (784b1ba1a2 and 8f8154a50). The attached
> moves
> pg_service.conf to use the new pg_get_line_append API and a StringInfo to lift
> the restriction. Any reason not to do that while we're lifting other such
> limits?
+1. I'd been thinking of looking around at our fgets calls to see
which ones need this sort of work, but didn't get to it yet.
Personally, I'd avoid depending on StringInfo.cursor here, as the
dependency isn't really buying you anything. Instead you could do
line = linebuf.data;
just after the trim-trailing-whitespace loop and then leave the
"ignore leading whitespace too" code as it stands.
Also, the need for inserting the pfree into multiple exit paths kind
of makes me itch. I wonder if we should change the ending code to
look like
exit:
fclose(f);
pfree(linebuf.data);
return result;
and then the early exit spots would be replaced with "result = x;
goto exit". (Some of them could use "break", but not all, so
it's probably better to consistently use "goto".)
regards, tom lane
