| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Should we represent temp files as unsigned long int instead of signed long int type? |
| Date: | 2023-10-26 00:40:55 |
| Message-ID: | ZTm1l12SJzUwQbpb@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Oct 25, 2023 at 03:07:39PM -0400, Tom Lane wrote:
> AFAIK, nothing particularly awful will happen if that counter wraps
> around. Perhaps if you gamed the system really hard, you could cause
> a collision with a still-extant temp file from the previous cycle,
> but I seriously doubt that could happen by accident. So I don't
> think there's anything to worry about here. Maybe we could make
> that filename pattern %lu not %ld, but minus sign is a perfectly
> acceptable filename character, so such a change would be cosmetic.
In the mood of removing long because it may be 4 bytes or 8 bytes
depending on the environment, I'd suggest to change it to either int64
or uint64. Not that it matters much for this specific case, but that
makes the code more portable.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-10-26 00:49:49 | Re: Should we represent temp files as unsigned long int instead of signed long int type? |
| Previous Message | David G. Johnston | 2023-10-26 00:10:17 | Re: Document aggregate functions better w.r.t. ORDER BY |