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

From Heikki Linnakangas
Subject Re: Extensions, this time with a patch
Date
Msg-id 4CEB99BA.7080403@enterprisedb.com
Whole thread Raw
In response to Re: Extensions, this time with a patch  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: SQL/MED estimated time of arrival?
Next
From: Shigeru HANADA
Date:
Subject: Re: SQL/MED estimated time of arrival?