Re: Extensions, this time with a patch

Поиск
Список
Период
Сортировка
От Itagaki Takahiro
Тема Re: Extensions, this time with a patch
Дата
Msg-id AANLkTimQTGgYYDd3osxWw0CcvWtUtJo2K5XvNz51XUbL@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Extensions, this time with a patch  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: Extensions, this time with a patch  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)
Следующее
От: Tom Lane
Дата:
Сообщение: dblink versus long connection strings