| 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: | Whole Thread | Raw Message | 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 |