Horton

Re: Lift line-length limit for pg_service.conf

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-09-21T15:09:23Z
Lists: pgsql-hackers 
Daniel Gustafsson <daniel@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

Commits

  1. Improve behavior of tsearch_readline(), and remove t_readline().

  2. Avoid possible dangling-pointer access in tsearch_readline_callback.

  3. Simplify SortTocFromFile() by removing fixed buffer-size limit.

  4. Remove arbitrary line length limit for libpq service files.

  5. Rethink API for pg_get_line.c, one more time.