Last summer, I wrote:
[ http://archives.postgresql.org/pgsql-hackers/2005-07/msg00320.php ]
>> It occurs to me that a cleaner solution would be to stop giving domain
>> types the same typinput routines as their base types. Instead, give
>> them all a specialized routine domain_in (comparable to array_in) that
>> first invokes the base type's input function and then applies any
>> relevant constraint checks.
> I did most of the work of coding this up, only to watch the idea
> crash and burn: datatype input routines aren't called at all for
> NULL values, so there's no way to enforce a NOT NULL domain constraint
> from the input routine.
The obvious solution to this, of course, is to allow datatype input
routines to be called for NULLs. We could check the functions'
strictness flag before doing so, so that the old behavior still
prevails for any input function marked strict, which is most of 'em.
When I first thought of this, a couple days ago, my immediate worry
was that it'd open a security hole: any C-language input function that
wasn't marked strict would crash the backend if passed a null input
string. However, any such function is *already* a security hole,
because it's been possible to call it manually for some time:
select int4in(null::cstring);
So there's no additional risk --- in fact, arguably having such a
function crash during normal input of NULL would be a Good Thing,
because it would make it far more likely that the mistake would get
noticed and fixed before someone used it as a form of DOS attack.
So that seems to leave only the objection that we'd still have to change
all the places that call input functions. But it's not like we've not
done that before (several times, even :-(). And making a change to
support non-strict input functions is still way nicer than introducing
explicit knowledge of domains in all these places.
Comments?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
