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.
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 |