Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> After looking closer, I think there are worse problems here: the code is
>> still using VARSIZE/VARDATA etc, which it should not be because the
>> field could easily be in 1-byte-header form.
> Well that's ok b
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> The other instance is in inv_api.c where it would be quite possible to use
>> fastgetattr() instead. But the column is always at the same fixed offset and
>> again it follows an int4 so it'll always be 4-byte ali
Gregory Stark <[EMAIL PROTECTED]> writes:
> The other instance is in inv_api.c where it would be quite possible to use
> fastgetattr() instead. But the column is always at the same fixed offset and
> again it follows an int4 so it'll always be 4-byte aligned and work fine. So
> for performance reas
Gregory Stark <[EMAIL PROTECTED]> writes:
> Well, it seems like it would be nice to mark which ones are and aren't unsafe
> rather than have them all be there waiting to trip people up.
We already do mark 'em --- that's what all the VARIABLE LENGTH FIELDS
START HERE comments are about. I'm not es
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Why do we even have those fields in the structs if they're unsafe to use?
>
> 1. genbki.sh
But genbki.sh wouldn't care if we #if 0 around the unsafe ones would it?
> 2. As you note, they're not always unsafe to
Gregory Stark <[EMAIL PROTECTED]> writes:
> Why do we even have those fields in the structs if they're unsafe to use?
1. genbki.sh
2. As you note, they're not always unsafe to use.
regards, tom lane
---(end of broadcast)---
