I was thinking a bit more about Alvaro's suggestion of the other day
that repalloc(NULL, size) should be allowed. I'm still convinced that
that's a bad idea, but it occurs to me that there is another corner
case in the palloc stuff that there's a better case for changing.
Specifically, I think we ought to allow palloc(0) and repalloc(x, 0).
What these should do is return a *non-NULL* pointer to a chunk of
minimum size.
The reason I'm thinking this is that I've lost count of the number of
places where we are kluging around the fact that palloc(0) elog's.
In most places the easiest fix is to waste storage, eg when you want
an array of n foo's you write something like
ptr = palloc(n * sizeof(foo) + 1);
if it's legitimate for n to be zero. This is confusing, wasteful,
and error-prone. (I'm sure there are still a bunch of places yet to
be found where we fail on zero-column tables because the +1 hasn't
gotten added.)
It's important that palloc(0) return an actual chunk, and not NULL,
for two reasons:
* If the result is later repalloc'd larger, it should stay in the
context that palloc was called in. There is no way to remember
that context without a chunk.
* The result should be pfree'able. I don't want to remove the
prohibition against pfree(NULL).
But assuming that we don't return NULL, this seems fully consistent
with the rest of the palloc API. It certainly doesn't break any
code that works today, and I think the change would eliminate many
special cases as well as future bug fixes.
Comments, objections?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
