On 10/14/2015 01:12 AM, Alvaro Herrera wrote:
> Amir Rohan wrote:
>> 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.
> I mean the utility would be built by using a file from the backend
> source, just like pg_xlogdump does. We have several such cases.
> I don't think this is impossible to do outside core, either.
I've considered "vendoring", but it seems like enough code surgery
be involved to make this very dubious "reuse". The language is simple
enough that writing a parser from scratch isn't a big deal hard, and
there doesn't seem much room for divergent parsing either.
So, the only question is whether reusing the existing parser will
brings along some highly useful functionality beyond an AST and
a battle-tested validator for bools, etc'. I'm not ruling anything
out yet, though.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: