Re: Garbage pad bytes within datums are bad news

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>> The alternative seems to be to forbid uninitialized pad bytes within
>>> Datums. That's not very pleasant to contemplate either, since it'll
>>> forever be vulnerable to sins of omission.
>
>> Just brainstorming here, I don't think this is a good solution but perhaps it
>> could lead somewhere interesting...

Another thought. Perhaps every data type should define an operator which is a
true equals. Ie, it guarantees that *no* internal state that any function
could expose is different between two datums. Most data types could implement
it just by calling memcmp (or postgres could provide such a definition if it's
left undefined).

That gives arrays the option of either providing such an operator or
guaranteeing no padding bytes and using memcmp.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!