| From: | Jacob Champion <jchampion(at)timescale(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | heath(dot)lord(at)crunchydata(dot)com, Daniel Gustafsson <daniel(at)yesql(dot)se>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17625: In PG15 PQsslAttribute returns different values than PG14 when SSL is not in use for the connection |
| Date: | 2022-09-29 20:40:09 |
| Message-ID: | CAAWbhmhYNOubS2qTx3rG8V2STZ9F0SrtRBuPJimCwRYAQ6r3BQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, Sep 29, 2022 at 1:16 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The intention seems to have been to change the
> behavior only for the conn == NULL case. So maybe we need to
> fix it as attached.
Yeah, that makes sense. Sorry for the oversight.
> This'd still be broken for the
> multiple-libraries scenario, but I admit that that's pretty
> hypothetical.
Since the goal is to let clients decide which connection options to
hardcode based on the SSL implementation, I think it stays
forward-compatible with multiple libraries, as long as this API
returns the "default" library that you get if you're an older,
clueless client. We would need a new API of some sort to let newer
clients figure out their choices.
Thanks,
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-09-29 20:45:32 | Re: BUG #17625: In PG15 PQsslAttribute returns different values than PG14 when SSL is not in use for the connection |
| Previous Message | Daniel Gustafsson | 2022-09-29 20:38:18 | Re: BUG #17625: In PG15 PQsslAttribute returns different values than PG14 when SSL is not in use for the connection |