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
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 |