Re: Extensions, this time with a patch - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: Extensions, this time with a patch
Date
Msg-id AANLkTimQTGgYYDd3osxWw0CcvWtUtJo2K5XvNz51XUbL@mail.gmail.com
Whole thread Raw
In response to Re: Extensions, this time with a patch  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Extensions, this time with a patch
List pgsql-hackers
On Mon, Nov 22, 2010 at 18:36, Dimitri Fontaine <dimitri@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)
Next
From: Tom Lane
Date:
Subject: dblink versus long connection strings