parsing pg_ident.conf

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

parsing pg_ident.conf

Andrew Dunstan

I noticed somewhat to my surprise as I was prepping the tests for the
"match the whole DN" patch that pg_ident.conf is parsed using the same
routines used for pg_hba.conf, and as a result the DN almost always
needs to be quoted, because they almost all contain a comma e.g.
"O=PGDG,OU=Testing". Even if we didn't break on commas we would probably
need to quote most of them, because it's very common to include spaces
e.g. "O=Acme Corp,OU=Marketing". Nevertheless it seems rather odd to
break on commas, since nothing in the file is meant to be a list - this
is a file with exactly three single-valued fields. Not sure if it's
worth doing anything about this, or we should just live with it the way
it is.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com



Reply | Threaded
Open this post in threaded view
|

Re: parsing pg_ident.conf

Fabien COELHO-3

Hello Andrew,

> I noticed somewhat to my surprise as I was prepping the tests for the
> "match the whole DN" patch that pg_ident.conf is parsed using the same
> routines used for pg_hba.conf, and as a result the DN almost always
> needs to be quoted, because they almost all contain a comma e.g.
> "O=PGDG,OU=Testing". Even if we didn't break on commas we would probably
> need to quote most of them, because it's very common to include spaces
> e.g. "O=Acme Corp,OU=Marketing". Nevertheless it seems rather odd to
> break on commas, since nothing in the file is meant to be a list - this
> is a file with exactly three single-valued fields. Not sure if it's
> worth doing anything about this, or we should just live with it the way
> it is.
My 0.02 €:

ISTM that having to quote long strings which may contains space or other
separators is a good thing from a readability point of view, even if it
would be possible to parse it without the quotes.

So I'm in favor of keeping it that way.

Note that since 8f8154a503, continuations are allowed on "pg_hba.conf" and
"pg_ident.conf", and that you may continuate within a quoted string, which
may be of interest when considering LDAP links.

--
Fabien.
Reply | Threaded
Open this post in threaded view
|

Re: parsing pg_ident.conf

Andrew Dunstan

On 11/20/20 2:19 AM, Fabien COELHO wrote:

>
> Hello Andrew,
>
>> I noticed somewhat to my surprise as I was prepping the tests for the
>> "match the whole DN" patch that pg_ident.conf is parsed using the same
>> routines used for pg_hba.conf, and as a result the DN almost always
>> needs to be quoted, because they almost all contain a comma e.g.
>> "O=PGDG,OU=Testing". Even if we didn't break on commas we would probably
>> need to quote most of them, because it's very common to include spaces
>> e.g. "O=Acme Corp,OU=Marketing". Nevertheless it seems rather odd to
>> break on commas, since nothing in the file is meant to be a list - this
>> is a file with exactly three single-valued fields. Not sure if it's
>> worth doing anything about this, or we should just live with it the way
>> it is.
>
> My 0.02 €:
>
> ISTM that having to quote long strings which may contains space or
> other separators is a good thing from a readability point of view,
> even if it would be possible to parse it without the quotes.
>
> So I'm in favor of keeping it that way.
>
> Note that since 8f8154a503, continuations are allowed on "pg_hba.conf"
> and "pg_ident.conf", and that you may continuate within a quoted
> string, which may be of interest when considering LDAP links.


Maybe we should add a comment at the top of the file about when quoting
is needed.


cheers


andrew



Reply | Threaded
Open this post in threaded view
|

Re: parsing pg_ident.conf

Fabien COELHO-3

>>> I noticed somewhat to my surprise as I was prepping the tests for the
>>> "match the whole DN" patch that pg_ident.conf is parsed using the same
>>> routines used for pg_hba.conf, and as a result the DN almost always
>>> needs to be quoted, because they almost all contain a comma e.g.
>>> "O=PGDG,OU=Testing". Even if we didn't break on commas we would probably
>>> need to quote most of them, because it's very common to include spaces
>
> Maybe we should add a comment at the top of the file about when quoting
> is needed.

Yes, that is a good place to point that out. Possibly it would also be
worth to add something in 20.2, including an example?

--
Fabien.