Horton

Re: Extensions, this time with a patch

Itagaki Takahiro <itagaki.takahiro@gmail.com>

View thread
From: Itagaki Takahiro <itagaki.takahiro@gmail.com>
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, David Fetter <david@fetter.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2010-11-22T16:09:54Z
Lists: 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