Re: Garbage pad bytes within datums are bad news - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Garbage pad bytes within datums are bad news
Date
Msg-id 8763uxfdcc.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Garbage pad bytes within datums are bad news  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> "Tom Lane" <tgl@sss.pgh.pa.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'sPostgreSQL training!
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Garbage pad bytes within datums are bad news
Next
From: Tom Lane
Date:
Subject: Re: Garbage pad bytes within datums are bad news