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 87hcehfhk1.fsf@oxford.xeocode.com
Whole thread Raw
In response to Garbage pad bytes within datums are bad news  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Garbage pad bytes within datums are bad news  (Tom Lane <tgl@sss.pgh.pa.us>)
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:

> 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...

We could have actual equal operators include an assertion that the datums are
also datumIsEqual? That isn't guaranteed to catch every case but it would be
good for complex data types like arrays.

I suppose if all we want to do is assert that constructors don't create this
situation we could have an assertion that calls the constructor a second time
(with palloc generating garbage data) and compares the results with
datumEqual.

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


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: modules
Next
From: Andrew Dunstan
Date:
Subject: Re: modules