Greetings,
>>>
>>>> - Reusing the GUC parser is something I would avoid as well. Not
>>>> worth
>>>> the complexity.
>>> Yes, I don't like it either. I will try to make guc-file.l frontend
>>> safe.
>> Any success with that?
>
> I looked into it and found that currently guc-file.c is built as part
> of guc.c, so it seems to be even more complicated to unbound
> guc-file.c from backend. Thus, I have some plan of how to proceed with
> patch:
>
> 1) Add guc-file.h and build guc-file.c separately from guc.c
>
> 2) Put guc-file.l / guc-file.h into common/*
>
> 3) Isolate all backend specific calls in guc-file.l with #ifdef FRONTEND
>
> Though I am not sure that this work is worth doing against extra
> redundancy added by simply adding frontend-safe copy of guc-file.l
> lexer. If someone has any thoughts I would be glad to receive comments.
>
I have finally worked it out. Now there is a common version of
guc-file.l and guc-file.c is built separately from guc.c. I had to use a
limited number of #ifndef FRONTEND, mostly to replace erreport calls.
Also, ProcessConfigFile and ProcessConfigFileInternal have been moved
inside guc.c explicitly as being a backend specific. So for me this
solution looks much more concise and neat.
Please, find the new version of patch attached. Tap tests have been
updated as well in order to handle both command line and postgresql.conf
specified restore_command.
Regards
--
Alexey Kondratov
Postgres Professional https://www.postgrespro.com
Russian Postgres Company
