Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files

From: Amir Rohan <amir(dot)rohan(at)zoho(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hacker mailing list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files
Date: 2015-10-13 22:03:16
Message-ID: 561D7FA4.2030408@zoho.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/14/2015 12:14 AM, Alvaro Herrera wrote:
> Amir Rohan wrote:
>
>> I've been considering that. Reusing the parser would ensure no errors
>> are introduces by having a different implementation, but on the other
>> hand involving the pg build in installation what's intended as a
>> lightweight, independent tool would hurt.
>> Because it's dubious whether this will end up in core, I'd like
>> "pip install pg_confcheck" to be all that is required.
>
> Maybe just compile a single file in a separate FRONTEND environment?
>

You mean refactoring the postgres like rhass means? could you elaborate?

I believe most people get pg as provided by their distro or PaaS,
and not by compiling it. Involving a pg build environment is asking a
whole lot of someone who has pg all installed and who just wants to lint
their conf.

It's also legitimate for someone to be configuring postgres
without having a clue how to compile it.

If this was in core, this wouldn't be an issue because then packages
would also include the tool. Note I'm not actually pushing for that,
it's that that has implications on what can be assumed as available.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2015-10-13 22:12:20 Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files
Previous Message Robert Haas 2015-10-13 21:59:56 Re: Parallel Seq Scan