Hi Dmitry,
On 30.11.2018 19:04, Dmitry Dolgov wrote:
> Just to confirm, patch still can be applied without conflicts, and pass all the
> tests. Also I like the original motivation for the feature, sounds pretty
> useful. For now I'm moving it to the next CF.
Thanks, although I have slightly updated patch to handle recent merge of
the recovery.conf into GUCs and postgresq.conf [1], new patch is attached.
>>
>>> - 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.
[1]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=2dedf4d9a899b36d1a8ed29be5efbd1b31a8fe85
Regards
--
Alexey Kondratov
Postgres Professional https://www.postgrespro.com
Russian Postgres Company