Re: SQL command to edit postgresql.conf, with comments

Josh Berkus wrote first:
>> Postgres has "COMMENT ON ..." SQL for various database objects and I
>> assumed that said comments would be stored in the system catalog.
>
> Oh. Now that's an interesting perspective ... you're suggesting that we
> take the comments and apply them as COMMENTS on the specific pg_settings?

Yes, something along those lines.

I should point out that in general I consider a "COMMENT ON" to just be a less
ambiguous form of a "-- " or "/* */" and that it would be a good idea for a code
or config parser to preserve comments given in the latter formats in the same
way it preserves the former when it can reasonably infer what to associate the
latter comments with.

> That wouldn't solve the issues of ordering, or of comments in the file
> not associated with a setting, but might be a good 80% solution.

Yes, and for something like this an 80% solution is good.

As for ordering, that can be handled with more metadata, like a "visual order"
number.

Tom Lane wrote second:
> Well, if the settings were stored in a catalog ... which they are not
> ... that might be a useful idea.

The catalog is where they *should* be stored, at least from the user's perspective.

> The reason that COMMENT ON isn't a terribly helpful analogy is that it
> puts the burden on the user to associate specific comment texts with
> specific database objects. The problem with parsing and modifying
> freestyle comments as seen in postgresql.conf is exactly (or mostly)
> that there's no reasonable way of mechanically determining which
> comments are associated with which setting. We could invent some
> arbitrary rule or other, but it'd have little to do with the way
> people perceive what's in such a file.

There's no reason that you can't have both kinds of comments. You could have
comments that are specially formatted such that the parser will then recognize
they are associated with something specific and so put them in the system
catalog. And then you can have other comments not formatted that way and the
parser will then pass over them like whitespace.

> I agree with Josh's proposal: keep mechanically-generated settings in a
> separate file, and don't even pretend to allow comments to be kept there.

I agree with the separate files approach as being the most practical in at least
the short term. However, I think that this file could support comments too, but
they would just be limited to end-of-line comments on the same line as the
setting, and it would be only these comments appearing in the system catalog by
default. Comments in the file for user editing would only appear in the catalog
if specially formatted, which for now could just mean taking end-of-line comments.

-- Darren Duncan