From: | Matthew Stickney <mtstickney(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [PATCH] (Windows) psql echoes password when reading from pipe |
Date: | 2018-05-22 20:56:40 |
Message-ID: | CAKH_Ld4j51U+k9_MHoA=HCx5=PP5i=6US7Lyum-2xXxAPZFG5A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | Postg토토 캔SQL : |
On Tue, May 22, 2018 at 4:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> [ please don't top-post ]
Sorry, I'm used to using a better mail client than this.
> Hm. The failure mode I was thinking about was insufficient resources
> to allocate another handle
You have a point here; CreateFile does create a new handle (as would
DuplicateHandle), while _fileno and _get_osfhandle just retrieve the
existing file descriptor and handle, respectively. I checked the docs
more carefully, and both calls should never fail unless the input
stream is invalid.
> But perhaps it's worth adding logic to deal with failure of the call?
I think it would be sufficient to check whether the SetConsoleMode
call fails, because that can fail even on a valid handle (e.g. if you
don't have a handle with write access). That would catch the case
where opening termin fails, too, although that might deserve it's own
check to get better error information.
simple_prompt seems to be used in a lot of different utilities for
different reasons; there seem to be a number of conventions for
reporting errors in src/port/ code, but it looks like other
interactive utilities generally print a message to stderr, and return
a basic success/failure value. Does that sound like the right
approach? I'm not sure if it's obvious how to handle errors in the
other utilities, but I can take a look.
-Matt Stickney
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2018-05-22 21:04:35 | Re: COPY FROM WITH HEADER skips a tuple every 4 billion tuples |
Previous Message | Mike Blackwell | 2018-05-22 20:35:10 | Re: [PATCH] Clear up perlcritic 'missing return' warning |