Joshua Tolley <eggyk...@gmail.com> writes: > On Sat, Nov 27, 2010 at 11:23:46AM -0500, Tom Lane wrote: >> There used to be a project of that name on gborg. I can't find the >> source code anymore though.
> How about > http://www.postgresql.org/ftp/projects/gborg/uniqueidentifier/stable/ Ah, thanks. >> The magic-block mechanism should prevent that. What I'm wondering about >> is whether the input function is (a) careless about null input and (b) >> not marked STRICT. > I think you're right: You're looking at the output function not the input function ... and indeed the first thing the input function does is to invoke strlen(), without any null check. > It should use PG_ARGISNULL(0), no? It'd be better to mark it STRICT in the SQL file (and likewise for the output function). Or actually what he *should* do is drop the whole thing and use the now-built-in uuid type. Now, this 2003-vintage tarball is obviously not what the OP is using, since it hasn't even got a PG_MODULE_MAGIC call. But if it hasn't been updated any more than that, this'd explain a core dump on NULL input. What's a bit less clear is how the null got into the source database without having triggered the same bug; but I suppose it might've been generated via INSERT DEFAULT VALUES or some such. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
