From: | "Dave Lee" <davelee(dot)com(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: migrating from mysql: need to convert empty string to null |
Date: | 2008-06-19 00:31:45 |
Message-ID: | cb13bf640806181731m4ea75eafra298371cc4153520@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Jun 18, 2008 at 3:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> There isn't any really nice way to do that :-(. You could put a wrapper
> function around int4in but it would not help, because the internal API
> for datatype input functions doesn't support having them return NULL
> (see InputFunctionCall in the sources).
I've read src/backend/utils/fmgr/README and it states that returning
NULL is just a matter of setting isnull to true in the
FunctionCallInfo struct, and provides a convenience macro,
PG_RETURN_NULL. But then, in InputFunctionCall, I presume you're
referring to the logic that that only allows NULL to be returned if
the source input string is also NULL, otherwise raising an error. At a
basic level, you're suggesting I need to take out this NULL check in
InputFunctionCall to get the capability I'm looking for?
Any idea why the input functions were designed this way? For users
migrating from other RDBMs, if no one else, being able to return NULL
from an input function seems to be a valuable feature. I might use
this hacked functionality to return NULL for '0000-00-00' dates which
MySQL foolishly accepts. Maybe it's only useful to former MySQL users
thanks,
Dave
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2008-06-19 00:39:59 | pg_locks "at-a-glance" view |
Previous Message | Scott Marlowe | 2008-06-18 21:53:09 | Re: renumber table |