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-22 09:36:01 |
Message-ID: | 87hbf9lmym.fsf@hi-media-techno.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> writes:
> I checked cfparser.v2.patch.
Thanks for reviewing it!
> It exports the static parseRecoveryCommandFileLine() in xlog.c
> as the global cfParseOneLine() in cfparser.c without modification.
>
> It generates one warning, but it can be easily fixed.
> cfparser.c:34: warning: no previous prototype for 'cfParseOneLine'
Mmmm, that must have been a cherry-picking error on my side, it seems I
forgot to include this patch in the cfparser branch. Sorry about that.
> Some discussions about the patch:
>
> * Is "cf" the best name for the prefix? Less abbreviated forms might
> be less confusable. Personally, I prefer "conf".
Will change accordingly if that's the choice.
> * Can we export ParseConfigFile() in guc-file.l rather than
> parseRecoveryCommandFileLine()? It can solve the issue that unquoted
> parameter values in recovery.conf are not recognized. Even if we
> won't merge them, just allowing unquoted values would be useful.
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.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Valentine Gogichashvili | 2010-11-22 11:21:28 | Re: final patch - plpgsql: for-in-array |
Previous Message | Itagaki Takahiro | 2010-11-22 06:37:31 | Re: [JDBC] Support for JDBC setQueryTimeout, et al. |