From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
Cc: | 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-22 16:09:54 |
Message-ID: | AANLkTimQTGgYYDd3osxWw0CcvWtUtJo2K5XvNz51XUbL@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 22, 2010 at 18:36, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
>> * Can we export ParseConfigFile() in guc-file.l rather than
>> parseRecoveryCommandFileLine()?
>
> Should we then consider recovery.conf entries as ordinary GUCs? That
> would allow to connect to a standby and issue 'show primary_conninfo'
> there. This has been asked before, already.
No. My suggestion was just to use the internal parser.
ParseConfigFile() returns parsed parameters as head_p and tail_p.
So, we can use it independently from GUC variables.
static bool
ParseConfigFile(const char *config_file, const char *calling_file,
int depth, GucContext context, int elevel,
struct name_value_pair **head_p,
struct name_value_pair **tail_p)
Special codes for "include" and "custom_variable_classes" in it
might not be needed to parse recovery.conf and extensions.
We would disable them when we parse non-guc configuration files.
Or, we could allow "include" in recovery.conf if we think it is
useful in some cases.
--
Itagaki Takahiro
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-22 16:27:46 | dblink versus long connection strings |
Previous Message | Magnus Hagander | 2010-11-22 15:47:55 | Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files) |