Re: CIDR in pg_hba.conf
От | Þórhallur Hálfdánarson |
---|---|
Тема | Re: CIDR in pg_hba.conf |
Дата | |
Msg-id | 20030507182904.G31225@tol.li обсуждение исходный текст |
Ответ на | Re: CIDR in pg_hba.conf ("Andrew Dunstan" <andrew@dunslane.net>) |
Список | pgsql-hackers |
I agree with this -*- Andrew Dunstan <andrew@dunslane.net> [ 2003-05-07 18:27 ]: > I would far rather have standard CIDR notation - inventing a new one for Pg > doesn't make sense to me. > > I do not at all understand the objection to a variable number of fields. In > fact, we already have them (there's an optional authentication_option on the > end). > > If you don't like this scheme, you can avoid use of CIDR notation (or > hostnames) and the pg_hba.conf will work exactly as before. > > andrew > > ----- Original Message ----- > From: "scott.marlowe" <scott.marlowe@ihs.com> > To: "D'Arcy J.M. Cain" <darcy@druid.net> > Cc: "Andrew Dunstan" <andrew@dunslane.net>; "PostgreSQL Hackers Mailing > List" <pgsql-hackers@postgresql.org> > Sent: Wednesday, May 07, 2003 1:44 PM > Subject: Re: [HACKERS] CIDR in pg_hba.conf > > > > On Wed, 7 May 2003, D'Arcy J.M. Cain wrote: > > > > > On Wednesday 07 May 2003 09:50, Andrew Dunstan wrote: > > > > So in hba.c, if we found a / in the IP address, we wouldn't go looking > for > > > > a separate netmask field. > > > > > > Is anyone else uncomfortable with variable number of fields? I know > there is > > > prior art but it still spooks me a little. How about a space after the > > > address and before the slash? That way the netmask is in the same field > as > > > always (as are the following fields) and it's just an alternative > syntax. > > > > If that's the case, then just drop the / from the address and make the > > mask field varialble, so if it has .s in it it's a netmask, otherwise it's > > a number like a CIDR's second half. > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org -- Kveðja, Tolli tolli@tol.li
В списке pgsql-hackers по дате отправления: