[Pgpool-hackers] removing backend_socket_dir parameter ?

[Guillaume Lelarge]

Le 04/01/2011 15:38, Jehan-Guillaume (ioguix) de Rorthais a écrit :
> Le 04/01/2011 15:13, Guillaume Lelarge a écrit :
>> Hi,
> 
>> Le 04/01/2011 14:27, Jehan-Guillaume (ioguix) de Rorthais a écrit :
>>> [...]
>>> pgPool is currently using the parameter "backend_socket_dir" to define where it
>>> can find the backend unix socket files.
>>>
>>> However, from the libpq world, we just use one parameter for both unix or inet
>>> socket: host. If this parameter starts with '/', then this is a unix socket. All
>>> other values are inet connections. See:
>>>
>>> http://www.postgresql.org/docs/9.0/static/libpq-connect.html#LIBPQ-CONNECT-HOST
>>>
>>> Back in pgPool world, the equivalent parameter is "backend_hostnameN". So, when
>>> I was setting up a dev environment yesterday, I naturally set this parameter  to
>>> my unix path (I'm using Debian) and end up with a hostname resolution error.
>>>
>>> So you'll find in attachment a patch to remove the "backend_socket_dir"
>>> parameter and use the libpq policy. Moreover, on empty "backend_hostnameN"
>>> value, the patch fall back to DEFAULT_SOCKET_DIR.
>>>
> 
>> This patch is really interesting. This is something I had on my todo
>> list for quite some time.
> 
> Glad to hear that :)
> I wasn't the only one wondering about this then :)
> 
>>> I realize it will break compatibility with older configuration file. But in a
>>> first step, I prefer something clean and start discussing this issue with you if
>>> you really mind this.
>>>
> 
>> On the configuration file, compatibility of configuration file is never
>> garantied. So I don't think this is such an issue. We need to make it
>> clear that the parameter has a new mail.
> 
> s/new mail/new name/
> 
> well, it's not a new name, we just drop one and promote an existing one to deal
> with both unix and inet socket :)
> 
>> If we really want to maintain the compatibility on this issue, we could
>> still support the old parameter during two or three major releases. I
>> guess we need to put a warning in the log to say "hey guy, you're still
>> using that old obsolete configuration parameter, you should better
>> change with this one".
> 
> Yeah. What I have in mind is :
>   if backend_hostnameN == ''
>     if not backend_socket_dir
>       backend_hostnameN = DEFAULT_SOCKET_DIR
>     else
>       log « please stop using that »
>       backend_hostnameN = backend_socket_dir
> 
> But really, I would prefer to drop backend_socket_dir and keep the code clean.
> 

You can't have it both ways. Either you please your users, or you please
your developpers. I think we should do the former.


-- 
Guillaume
 http://www.postgresql.fr
 http://dalibo.com