Gregory Stark <[EMAIL PROTECTED]> writes:
> 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.
After further
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> 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
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> That still puts the responsibility on the individual datatype author to
>> get it right. The case I'm most worried about is user-written datatypes
>> that are never going to magically acquire such asserts.
> It seems to me that working with two assumpt
That still puts the responsibility on the individual datatype author to
get it right. The case I'm most worried about is user-written datatypes
that are never going to magically acquire such asserts.
It seems to me that working with two assumption (binary equal and
catalog-defined equal fun
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> 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
"Tom Lane" <[EMAIL PROTECTED]> 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 perh
Teodor Sigaev <[EMAIL PROTECTED]> 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.
> Hmm, we can add to palloc random filling of allocated memory wit
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.
Hmm, we can add to palloc random filling of allocated memory with
--enable-cassert. It'll allow to catch such b
I tracked down the problem reported here:
http://archives.postgresql.org/pgsql-admin/2008-04/msg00038.php
What it boils down to is that equal() doesn't see these two Consts
as equal:
{CONST
:consttype 1009
:consttypmod -1
:constlen -1
