| From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
|---|---|
| To: | "David Fetter *EXTERN*" <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: POLA violation with \c service= |
| Date: | 2014-12-17 08:03:22 |
| Message-ID: | A737B7A37273E048B164557ADEF4A58B17DAEC51@ntex2010a.host.magwien.gv.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Fetter wrote:
> I've noticed that psql's \c function handles service= requests in a
> way that I can only characterize as broken.
>
> This came up in the context of connecting to a cloud hosting service
> named after warriors or a river or something, whose default hostnames
> are long, confusing, and easy to typo, so I suspect that service= may
> come up more often going forward than it has until now.
>
> For example, when I try to use
>
> \c "service=foo"
>
> It will correctly figure out which database I'm trying to connect to,
> but fail to notice that it's on a different host, port, etc., and
> hence fail to connect with a somewhat unhelpful error message.
>
> I can think of a few approaches for fixing this:
>
> 0. Leave it broken.
> 1. Disable "service=" requests entirely in \c context, and error out if attempted.
> 2. Ensure that \c actually uses all of the available information.
>
> Is there another one I missed?
>
> If not, which of the approaches seems reasonable?
#2 is the correct solution, #1 a band aid.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2014-12-17 08:35:49 | Re: Logical Decoding follows timelines |
| Previous Message | Simon Riggs | 2014-12-17 07:55:29 | Re: Yet another abort-early plan disaster on 9.3 |