Thread: pg_service.conf file with iso-8859-1 parameters

pg_service.conf file with iso-8859-1 parameters

From
Magnus Hagander
Date:
Right now, pg_service.conf returns "syntax error" if it encounters a parameter it doesn't know about.

This seems user-unfriendly, both in the error message (because it really isn't a syntax error) and in the behaviour itself (because it doesn't work when sometimes it should).

For example, if I have a service file with gssencmode=disable set, that service file cannot be used by a psql client linked against libpq from version 10. Even if the behavior would be identical (since v10 doesn't have gssencmode).

Is there a particular reason we (1) refuse unknown parameters in the file, and (2) call it a "syntax error"?

The documentation just says it's "INI format" file -- though in my experience most other INI file parsers just ignore extra parameters included..

//Magnus

Re: pg_service.conf file with iso-8859-1 parameters

From
Bruce Momjian
Date:
On Fri, Sep 11, 2020 at 02:39:51PM +0200, Magnus Hagander wrote:
> Right now, pg_service.conf returns "syntax error" if it encounters a parameter
> it doesn't know about.
> 
> This seems user-unfriendly, both in the error message (because it really isn't
> a syntax error) and in the behaviour itself (because it doesn't work when
> sometimes it should).
> 
> For example, if I have a service file with gssencmode=disable set, that service
> file cannot be used by a psql client linked against libpq from version 10. Even
> if the behavior would be identical (since v10 doesn't have gssencmode).
> 
> Is there a particular reason we (1) refuse unknown parameters in the file, and
> (2) call it a "syntax error"?
> 
> The documentation just says it's "INI format" file -- though in my experience
> most other INI file parsers just ignore extra parameters included..

My guess is that because the file can contain passwords, we want to
report as little as possible on error.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee




Re: pg_service.conf file with iso-8859-1 parameters

From
Daniel Gustafsson
Date:
> On 11 Sep 2020, at 14:39, Magnus Hagander <magnus@hagander.net> wrote:

> For example, if I have a service file with gssencmode=disable set, that service file cannot be used by a psql client
linkedagainst libpq from version 10. Even if the behavior would be identical (since v10 doesn't have gssencmode). 
>
> Is there a particular reason we (1) refuse unknown parameters in the file,

The above case is a good example when silently ignoring would be beneficial.
We would however run the risk that someone has this in their service which is
silently ignored and fails to notice:

  ssl_mim_protocol_version=TLSv1.3

Not sure if that's worth the risk?  Halting on unknown parameters is also
consistent with postgresql.conf parsing etc (which isn't a clientside file I
know, but still relevant IMO).

> and (2) call it a "syntax error"?

That I agree with isn't entirely correct, the syntax is correct but the
parameter is unknown. Something along the following seems more correct:

  -  libpq_gettext("syntax error in service file \"%s\", line %d\n"),
  +  libpq_gettext("unknown parameter in service file \"%s\", line %d\n"),

> The documentation just says it's "INI format" file -- though in my experience most other INI file parsers just ignore
extraparameters included.. 

I don't think the INI file format is formally defined anywhere, but I do
believe it's considered to be strictly key-values (Wikipedia [0] agrees with
that).  Since we allow ldap configurations like the one below, it's technically
not INI format though:

  [service=mydb]
  ldap://127.0.0.1:10000/foo?bar?lorem?ipsum

That might be borderline hairsplitting, but perhaps calling it INI format in
the docs isn't really helping?  Maybe we should reword that to say key/value or
something similar?

And this brings up an even more interesting case, the above will yield a syntax
error if libpq wasn't compiled with LDAP support, as opposed to other
parameters (like SSL* etc) which are ignored for builds not supporting them.
Is there a reason to treat ldap differently?

cheers ./daniel

[0] https://en.wikipedia.org/wiki/INI_file