Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >> It might work to change struct varlena's contents to something like
> >>
> >> char vl_len_[4]; /* Do not touch this field directly! */
> >> char vl_dat[1];
>
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> It might work to change struct varlena's contents to something like
>>
>> char vl_len_[4]; /* Do not touch this field directly! */
>> char vl_dat[1];
> Oh, that would probably fix this proble
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> I can't say that I find this a nice clean solution; but does anyone have
>>> a better one?
>
>> I'm thinking instead of having struct varlena (which you're not allowed t
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> I can't say that I find this a nice clean solution; but does anyone have
>> a better one?
> I'm thinking instead of having struct varlena (which you're not allowed to
> safely use any members of anyways) we shoul
"Tom Lane" <[EMAIL PROTECTED]> writes:
> After much experimentation I was able to get it to work by invoking
> memcpy through a function pointer, which seems to be sufficient to
> disable this particular compiler's built-in intelligence about memcpy.
> I can't say that I find this a nice clean sol
I got around to testing PG 8.3 on HPUX on Itanium (feel free to play
along at www.testdrive.hp.com) ... and was dismayed to find that it
doesn't work. If compiled with HP's C compiler, the regression tests
dump core. Investigation shows that the problem occurs where
tuptoaster.c tries to copy a m
