Re: Garbage pad bytes within datums are bad news
От | Gregory Stark |
---|---|
Тема | Re: Garbage pad bytes within datums are bad news |
Дата | |
Msg-id | 87hcehfhk1.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Garbage pad bytes within datums are bad news (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Garbage pad bytes within datums are bad news
Re: Garbage pad bytes within datums are bad news |
Список | 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 по дате отправления: