From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Antonin Houska <ah(at)cybertec(dot)at>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Return value of PathNameOpenFile() |
Date: | 2022-09-06 18:47:49 |
Message-ID: | 95EEA870-F018-43FE-A6BC-853D9E6794F4@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 6 Sep 2022, at 16:12, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> Agreed, zero should be valid as it's a non-negative integer. However, callers
>> in fd.c are themselves checking for (fd <= 0) in some cases, and some have done
>> so since the very early days of the codebase, so I wonder if there historically
>> used to be a platform which considered 0 an invalid fd?
>
> I'm betting it's a thinko that never got caught because 0 would
> always be taken up by stdin. Maybe you'd notice if you tried to
> close-and-reopen stdin, but that's not something the server ever does.
Doh, of course. The attached is a quick (lightly make check tested) take on
allowing 0, but I'm not sure that's what we want?
--
Daniel Gustafsson https://vmware.com/
Attachment | Content-Type | Size |
---|---|---|
pathnameopenfile_fd0.diff | application/octet-stream | 3.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-09-06 18:50:14 | Re: allowing for control over SET ROLE |
Previous Message | Jeff Davis | 2022-09-06 18:45:54 | Re: allowing for control over SET ROLE |