Re: Extensions, this time with a patch

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extensions, this time with a patch
Date: 2010-11-24 20:02:41
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> writes:
> RECOVERY_COMMAND_FILE is opened twice in the patch. The first time
> is for checking the existence, and the second time is for parsing.
> Instead of the repeat, how about adding FILE* version of parser?
> It will be also called from ParseConfigFile() as a sub routine.
> bool ParseConfigFd(FILE *fd, const char *config_file, int depth, ...)

Something like the attached, version 5 of the patch? I've been using the
function name ParseConfigFp because the internal parameter was called fp
in the previous function body. I suppose that could easily be changed at
commit time if necessary.

> BTW, the parser supports "include" and "custom_variable_classes"
> not only for postgresql.conf but also for all files. Is it an
> intended behavior? I think they are harmless, so we don't have
> to change the codes; "include" might be useful even in recovery.conf,
> and "custom_variable_classes" will be "unrecognized recovery
> parameter" error after all.

Extensions will need the support for custom_variable_classes as it is
done now, and as you say, the recovery will just error out. You have to
clean your recovery.conf file then try again (I just tried and confirm).

I personally don't see any harm to have the features in all currently
known uses-cases, and I don't see any point in walking an extra mile
here to remove a feature in some cases.

Dimitri Fontaine PostgreSQL : Expertise, Formation et Support

Attachment Content-Type Size
cfparser.v5.patch text/x-patch 21.3 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-11-24 20:06:47 Re: profiling connection overhead
Previous Message Tom Lane 2010-11-24 19:59:27 Re: profiling connection overhead