Re: postgresql.auto.conf comments - Mailing list pgsql-hackers

From Thom Brown
Subject Re: postgresql.auto.conf comments
Date
Msg-id CAA-aLv6M8vi_ZV_6D8DCmgPGLUW+vUpdZQL9Lin8KWaNnKDbmA@mail.gmail.com
Whole thread Raw
In response to Re: postgresql.auto.conf comments  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: postgresql.auto.conf comments  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 24 November 2014 at 21:04, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Nov 24, 2014 at 3:26 PM, Thom Brown <thom@linux.com> wrote:
> I haven't seen this mentioned anywhere (although it may have as I haven't
> read through the entire history of it), but would others find it useful to
> have ALTER SYSTEM support comments?

Oh, please no.

The main thing that caused us to have no way of modifying
postgresql.conf via SQL for so many years is that it's not clear how
you can sensibly rewrite a file with comments in it.  For example, the
default postgresql.conf file has stuff like this in it:

#variable = someval

If variable gets set to a non-default value, you might want to
uncomment that line, but now you have to parse the comments, which
will be tedious and error-prone and sometimes make stupid decisions:

#Back in days of yore when dinosaurs ruled the earth, we had
#autovacuum_naptime=1h, but that turned out to be a bad idea.
#
#autovacuum_naptime=1min

I'm not sure this is an argument against supporting comments to postgresql.auto.conf since it's specifically intended not to be edited by humans, and commenting out a parameter will remove it from the file upon further ALTER SYSTEM invocations anyway.

It would perhaps be OK to have comments in postgresql.conf.auto if
they were designated in some way that told us which specific comment
was associated with which specific setting.  But we need to be very
careful not to design something that requires us to write a parser
that can ferret out human intent from context clues. 

Perhaps the parser could automatically remove any comment blocks which are followed by a blank/empty line.

So if we had:

---------------------
work_mem = '4MB'
# Set this lower as we're using a really fast disk interace
#seq_page_cost = '0.5'

# Set random_page_cost lower as we're using an SSD
random_page_cost = '1.0'
# This line has been manually added by a human without a newline
maintenance_work_mem = '1GB'

# This is an orphaned comment
---------------------

I would expect the next modification to the file to cause reduce it to:

---------------------
work_mem = '4MB'

# Set random_page_cost lower as we're using an SSD
random_page_cost = 1.0

# This line has been manually added
maintenance_work_mem = '1GB'
---------------------
 
Thom

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: postgresql.auto.conf comments
Next
From: Adam Brightwell
Date:
Subject: CATUPDATE confusion?