From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_service.conf file with unknown parameters |
Date: | 2020-09-21 11:28:08 |
Message-ID: | 7E3E2E15-D8EA-4D12-9FB0-718A0B265755@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 11 Sep 2020, at 14:39, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> 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,
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 extra parameters 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
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2020-09-21 11:32:35 | Re: Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c) |
Previous Message | Amit Kapila | 2020-09-21 11:24:31 | Re: [HACKERS] logical decoding of two-phase transactions |