Re: [PATCH] (Windows) psql echoes password when reading from pipe

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: [PATCH] (Windows) psql echoes password when reading from pipe
Дата
в 23:09:06
Msg-id
18079.1527019746@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
[PATCH] (Windows) psql echoes password when reading from pipe Matthew Stickney <mtstickney@gmail.com>
Re: [PATCH] (Windows) psql echoes password when reading from pipe Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCH] (Windows) psql echoes password when reading from pipe Matthew Stickney <mtstickney@gmail.com>
Re: [PATCH] (Windows) psql echoes password when reading from pipe Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCH] (Windows) psql echoes password when reading from pipe Matthew Stickney <mtstickney@gmail.com>
Re: [PATCH] (Windows) psql echoes password when reading from pipe Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCH] (Windows) psql echoes password when reading from pipe Matthew Stickney <mtstickney@gmail.com>
Re: [PATCH] (Windows) psql echoes password when reading from pipe Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCH] (Windows) psql echoes password when reading from pipe Matthew Stickney <mtstickney@gmail.com>
[ please don't top-post ]

Matthew Stickney  writes:
> On Tue, May 22, 2018 at 2:55 PM, Tom Lane  wrote:
>> Is it possible to operate on "termin" instead of doing a second open
>> (which might fail, which we are failing to cope with :-()?

> It is possible, at the cost of two extra function calls, which could
> theoretically fail (and require a little extra munging to work on
> Windows CE -- is that a target platform for postgres?).

AFAIK we don't claim to support CE.

> Similar to using CreateFile, I think the cases in which those calls
> could fail are so extraordinary that psql probably wouldn't run at all
> (i.e. there's no console for the process, in which case psql would
> crash as soon as it attempted to do IO). It also requires opening
> termin with "w+", because SetConsoleMode needs write permissions. You
> could avoid that by doing a DuplicateHandle on the underlying handle
> that you retrieve from termin, but I doubt it's worth it.

Hm.  The failure mode I was thinking about was insufficient resources
to allocate another handle; so it seems like all of these are more or
less equivalent on that basis, and we might as well go with whatever's
shortest.  But perhaps it's worth adding logic to deal with failure
of the call?  Or can we expect the additional calls to fall through
silently anyway if given an invalid handle?  (If so, maybe a comment
about that is sufficient.)

			regards, tom lane

В списке pgsql-hackers по дате отправления
От: Andres Freund
Дата:
От: Mike Blackwell
Дата:
FAQ