Re: [PATCH] (Windows) psql echoes password when reading from pipe
От | Tom Lane |
---|---|
Тема | Re: [PATCH] (Windows) psql echoes password when reading from pipe |
Дата | |
Msg-id | 18079.1527019746@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
|
Список | pgsql-hackers |
[ please don't top-post ] Matthew Stickney <mtstickney@gmail.com> writes: > On Tue, May 22, 2018 at 2:55 PM, Tom Lane <tgl@sss.pgh.pa.us> 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 по дате отправления: