On Tue, Aug 1, 2023 at 11:07 AM Tristan Partin wrote:
> A new API design would be great, but for right now v2 is good enough and
> should be committed. It is much easier to read the code with this patch
> applied.
>
> Marking as "Ready for Committer" since we all seem to agree that this is
> bette
On Wed Apr 19, 2023 at 8:09 AM CDT, Robert Haas wrote:
On Tue, Apr 18, 2023 at 12:56 PM Dagfinn Ilmari Mannsåker
wrote:
> It still has magic numbers for the sizes of the fields, should those
> also be named constants?
I thought about that. It's arguable, but personally, I don't think
it's worth
On Tue, Apr 18, 2023 at 12:56 PM Dagfinn Ilmari Mannsåker
wrote:
> It still has magic numbers for the sizes of the fields, should those
> also be named constants?
I thought about that. It's arguable, but personally, I don't think
it's worth it. If the concern is greppability, having constants for
Robert Haas writes:
> On Tue, Apr 18, 2023 at 12:06 PM Tom Lane wrote:
>> Hmm, you're right: I checked the POSIX.1-2018 spec as well, and
>> it agrees that the prefix field is 155 bytes long. Perhaps just
>> add another comment line indicating that 12 bytes remain unassigned?
>
> OK. Here's v2,
Robert Haas writes:
> OK. Here's v2, with that change and a few others.
LGTM.
regards, tom lane
On Tue, Apr 18, 2023 at 12:06 PM Tom Lane wrote:
> Hmm, you're right: I checked the POSIX.1-2018 spec as well, and
> it agrees that the prefix field is 155 bytes long. Perhaps just
> add another comment line indicating that 12 bytes remain unassigned?
OK. Here's v2, with that change and a few ot
Robert Haas writes:
> On Tue, Apr 18, 2023 at 11:38 AM Tom Lane wrote:
>> 2. The header size is defined as 512 bytes, but this doesn't sum to 512:
>> + TAR_OFFSET_PREFIX = 345 /* 155 byte string */
> I think that what happened is that whoever designed the original tar
> format deci
On Tue, Apr 18, 2023 at 11:38 AM Tom Lane wrote:
> Robert Haas writes:
> > We have a few different places in the code where we generate or modify
> > tar headers or just read data out of them. The code in question uses
> > one of my less-favorite programming things: magic numbers. The offsets
> >
Robert Haas writes:
> We have a few different places in the code where we generate or modify
> tar headers or just read data out of them. The code in question uses
> one of my less-favorite programming things: magic numbers. The offsets
> of the various fields within the tar header are just hard-c
