Re: Wildcard usage enhancements in .pgpass

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alexey Klyukin <alexk(at)hintbits(dot)com>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Wildcard usage enhancements in .pgpass
Date: 2013-11-19 15:44:22
Message-ID: CA+TgmoYaeZJBvNOFt+4AopHxXJyiaLnBsZHnDd3L-QUdk+YX1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 18, 2013 at 1:57 AM, Alexey Klyukin <alexk(at)hintbits(dot)com> wrote:
> Hi Martijn,
>
> On Sun, Nov 17, 2013 at 7:56 PM, Martijn van Oosterhout <kleptog(at)svana(dot)org>
> wrote:
>>
>> On Sat, Nov 16, 2013 at 09:26:33PM +0100, Alexey Klyukin wrote:
>> > Hi,
>> >
>> > Attached is the patch that improves usage of '*' wildcard in .pgpass,
>> > particularly in the host part. The use case is below.
>>
>> Looks interesting, though I wonder if you could use fnmatch(3) here. Or
>> woud that match more than you expect? For example, it would allow
>> 'foo*bar' to match 'foo.bar' which your code doesn't.
>
> fnmatch(3) looks like a good deal and I'd certainly consider it if we go the
> road of matching regular expressions, although for simpler use cases it's an
> overkill, since it forces us to do an extra pass over the string to be
> matched and introduces some performance penalties of using a regexp matching
> engine.

Also, it seems likely that it's not supported on every platform (e.g.
Windows), possibly then requiring a src/port implementation. I'd
rather avoid introducing new platform dependencies unless they do
something really key.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christophe Pettus 2013-11-19 15:46:33 Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1
Previous Message Andres Freund 2013-11-19 15:43:08 Re: better atomics - v0.2