Re: Lift line-length limit for pg_service.conf

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Lift line-length limit for pg_service.conf
Date: 2020-09-21 15:09:23
Message-ID: 934787.1600700963@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-09-21 15:36:32 Re: PGXS testing upgrade paths
Previous Message James Coleman 2020-09-21 14:45:53 PGXS testing upgrade paths