Re: [HACKERS] Is it time to kill support for very old servers?
| От | Andres Freund |
|---|---|
| Тема | Re: [HACKERS] Is it time to kill support for very old servers? |
| Дата | |
| Msg-id | D2D21DED-5ED0-4D18-93EB-28C7FE808A5B@anarazel.de обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Is it time to kill support for very old servers? (Michael Paquier <michael.paquier@gmail.com>) |
| Ответы |
Re: [HACKERS] Is it time to kill support for very old servers?
Re: [HACKERS] Is it time to kill support for very old servers? |
| Список | pgsql-hackers |
On September 18, 2017 4:15:31 AM PDT, Michael Paquier <michael.paquier@gmail.com> wrote: >On Mon, Sep 18, 2017 at 8:09 PM, Andres Freund <andres@anarazel.de> >wrote: >> >> >> On September 18, 2017 4:08:21 AM PDT, Michael Paquier ><michael.paquier@gmail.com> wrote: >>>On Mon, Sep 18, 2017 at 7:54 PM, Andres Freund <andres@anarazel.de> >>>wrote: >>>>>It seems to me that you are looking more for a connection parameter >>>>>here. >>>> >>>> I'm not seeing a meaningful distinction here? Env vars and >connection >>>parameters are handled using the same framework in libpq. And using >>>the env var in the test would be better, because you'd only set one >>>value - hard to do within our non TAP tests (i.e. in an existing >psql, >>>started by pg regress) otherwise. >>> >>>Or both? I don't really understand why an environment variable is >>>better than a connection string. For the TAP tests, you could just >set >>>the base of the connection string once and you are done as well. See >>>the SSL tests for example. >> >> Did you read what I wrote? > >Sorry, I missed the "non" with "TAP" tests. Having a connection >parameter would still be low-cost in maintenance, so if you add that >at the same time I won't complain. Private: And now you missed the "same infrastructure" part. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: