Re: Extensions, this time with a patch
От | Heikki Linnakangas |
---|---|
Тема | Re: Extensions, this time with a patch |
Дата | |
Msg-id | 4CEB99BA.7080403@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Extensions, this time with a patch (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On 22.11.2010 03:35, Robert Haas wrote: > On Sun, Nov 21, 2010 at 8:10 PM, Itagaki Takahiro > <itagaki.takahiro@gmail.com> wrote: >> On Wed, Oct 20, 2010 at 01:36, Dimitri Fontaine<dimitri@2ndquadrant.fr> wrote: >>> Ah yes, thinking it's an easy patch is not helping. Please find attached >>> a revised version of it. >> >> I checked cfparser.v2.patch. >> >> 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' >> >> Some discussions about the patch: >> >> * Is "cf" the best name for the prefix? Less abbreviated forms might >> be less confusable. Personally, I prefer "conf". >> >> * 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. > > I'd really like to see postgresql.conf and recovery.conf parsing > merged, and I suspect, as Itagaki-san says, that postgresql.conf > parsing is the better model for any new code. +1. There was unanimous agreement in the synchronous replication threads that recovery.conf should be parsed with the GUC parser. The current recovery.conf parser doesn't support escaping, for example. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: