Re: Why repalloc() != realloc() ?

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> Is there a reason why repalloc() does not behave the same as realloc?
> realloc(NULL, size) behaves the same as malloc(size), and it seems
> useful behavior -- I wonder why repalloc() chooses to Assert() against
> this exact condition?

We don't allow palloc(0) either, and we don't return NULL on failure,
and for that matter we don't allow pfree(NULL). Please don't argue that
"we ought to be just like libc".

> I assume this is because the NULL pointer would not know what context it
> belongs to,

That's a sufficient reason from my point of view. One of the main
properties of repalloc is that the alloc'd memory stays in the same
context it was first allocated in. I'm not excited about allowing
a special exception that makes that behavior less predictable.

To give a concrete example of why this sort of corner-case exception is
bad, imagine an aggregate function or similar thing that concatenates
strings. It starts with a palloc() in a specific context and then
assumes that repalloc's will stay in that context without prodding.
The code works fine --- unless there are corner cases for palloc(0)
returning NULL and repalloc() accepting NULL.

> Can this behavior be changed?

Not without a significantly better argument than you've offered.

regards, tom lane