Re: Manipulating complex types as non-contiguous structures in-memory

On 2015-05-13 21:01:43 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2015-05-13 20:48:51 -0400, Tom Lane wrote:
> >> I still think that going back to defining the second byte as the size
> >> would be better. Fortunately, since this is only a matter of in-memory
> >> representations, we aren't committed to any particular answer.
>
> > Requiring sizes to be different still strikes me as a disaster. Or is
> > that not what you're proposing?
>
> It is, but why would it be a disaster? We could add StaticAsserts
> verifying that the sizes actually are different. I doubt that the pad
> space itself could amount to any issue performance-wise, since it would
> only ever exist in transient in-memory tuples, and even that only seldom.

The sizes would be platform dependant. It's also just incredibly ugly to
have to add pad bytes to structures so we can disambiguate them.

Anyway, I think we can live with your & or my proposed additional branch
for now. I can't see either variant being a relevant performance
bottleneck anytime soon.