On Tue, Apr 11, 2023 at 02:43:25PM +0900, Michael Paquier wrote:
> After going through the installation of a Windows setup with meson and
> ninja under VS, I have checked that this is working correctly by
> myself, so I am going to apply that. One of the tests I have done
> involved feeding a dump
On Mon, Mar 20, 2023 at 07:06:22AM +0900, Michael Paquier wrote:
> Not sure about this one. I have considered it and dirmod.c includes
> also bits for cygwin, while being aimed for higher-level routines like
> rename(), unlink() or symlink(). This patch is only for WIN32, and
> aimed for common p
On Mon, Mar 20, 2023 at 07:06:22AM +0900, Michael Paquier wrote:
> Not sure about this one. I have considered it and dirmod.c includes
> also bits for cygwin, while being aimed for higher-level routines like
> rename(), unlink() or symlink(). This patch is only for WIN32, and
> aimed for common p
On Sun, Mar 19, 2023 at 08:10:10PM +0100, Juan José Santamaría Flecha wrote:
> My approach was trying to make something minimal so it could be
> backpatchable. This looks fine for HEAD, but are you planning on something
> similar for the other branches?
Yes. This is actually not invasive down to
On Sun, Mar 19, 2023 at 12:45 PM Michael Paquier
wrote:
>
> In short, I was thinking among the lines of something like the
> attached, where I have invented a pgwin32_get_file_type() that acts as
> a wrapper of GetFileType() in a new file called win32common.c, with
> all the error handling we wou
On Sun, Mar 19, 2023 at 08:20:27PM +0900, Michael Paquier wrote:
> I am not sure, TBH. As presented, the two GetFileType() calls in
> _pgftello64() and _pgfseeko64() ignore the case where it returns
> FILE_TYPE_UNKNOWN and GetLastError() has something else than
> NO_ERROR. The code would return E
On Thu, Mar 16, 2023 at 10:08:44AM +0100, Juan José Santamaría Flecha wrote:
> IDK, this is just looking for the good case, anything else we'll fail with
> ESPIPE or EINVAL anyway. If we want to get the proper file type we can call
> fstat(), which has the full logic.
I am not sure, TBH. As prese
On Thu, Mar 16, 2023 at 2:05 AM Michael Paquier wrote:
> On Wed, Mar 15, 2023 at 12:18:25PM +0100, Juan José Santamaría Flecha
> wrote:
> > PFA a new version of the patch.
>
> +_pgftello64(FILE *stream)
> +{
> + DWORD fileType;
> +
> + fileType = GetFileType((HANDLE) _get_osfhandle(
On Wed, Mar 15, 2023 at 12:18:25PM +0100, Juan José Santamaría Flecha wrote:
> PFA a new version of the patch.
+_pgftello64(FILE *stream)
+{
+ DWORD fileType;
+
+ fileType = GetFileType((HANDLE) _get_osfhandle(_fileno(stream)));
Hmm. I am a bit surprised here.. It seems to me that
On Wed, Mar 15, 2023 at 5:57 AM Michael Paquier wrote:
> On Tue, Mar 14, 2023 at 01:26:27PM +0100, Juan José Santamaría Flecha
> wrote:
> > As highlighted in [1] fseek() might fail to error even when accessing
> > unseekable streams.
> >
> > PFA a patch that checks the file type before the actual
On Tue, Mar 14, 2023 at 01:26:27PM +0100, Juan José Santamaría Flecha wrote:
> As highlighted in [1] fseek() might fail to error even when accessing
> unseekable streams.
>
> PFA a patch that checks the file type before the actual fseek(), so only
> supported calls are made.
+ * streams, so harde
Hello all,
As highlighted in [1] fseek() might fail to error even when accessing
unseekable streams.
PFA a patch that checks the file type before the actual fseek(), so only
supported calls are made.
[1]
https://www.postgresql.org/message-id/flat/b1448cd7-871e-20e3-8398-895e2d1d3...@gmail.com
R
12 matches
Mail list logo
