Re: replace all with * in pg_hba.conf

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To:
Cc: Postgresql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: replace all with * in pg_hba.conf
Date: 2003-12-18 20:17:26
Message-ID: 3FE20B56.3000705@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

I wrote:

> Peter Eisentraut wrote:
>
>> Andrew Dunstan wrote:
>>
>>
>>> If people are happy with Tom's suggestion of using '*' instead of
>>> 'all' in pg_hba.conf I will prepare a patch for it.
>>>
>>
>>
>> Well, while we're breaking stuff in the name of improvement, what
>> about databases named "*" or databases with spaces in their names?
>>
>>
>
> Good point. Perhaps we need to provide for an escaping mechanism in
> the routines that parse the file, although personally I have little
> sympathy for anyone who names a database '*'. I think it comes into
> the category of "Doctor, it hurts when I do this" ... "Then stop doing
> that." Spaces are a more likely problem, especially when we get W32
> native users.

Looking at the code I discover that there is already provision covering
spaces etc., because you can quote names. It's even documented ;-)

The minimal disturbance change might be to teach the parser to
distinguish between a quoted 'all' and an unquoted 'all', and forget the
'*' idea. Alternatively, do the same sort of thing, but replacing 'all'
with '*'. A patch for the first would be quite tiny - similar for '*'
except for extra doc and sample file changes.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin Sherry 2003-12-18 21:38:35 Re: Why isn't DECLARE CURSOR ... FOR UPDATE supported?
Previous Message Peter Eisentraut 2003-12-18 18:58:44 Re: 7.4 include file conflict

Browse pgsql-patches by date

  From Date Subject
Next Message Peter Eisentraut 2003-12-18 20:28:51 Re: [GENERAL] restore error - language "plperlu" is not trusted
Previous Message Kurt Roeckx 2003-12-18 19:18:08 Re: ISO year.