Re: [HACKERS] Fixing domain input
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
Re: [HACKERS] Fixing domain input
On Apr 4, 2006, at 10:39 , Tom Lane wrote: 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. Granted, finding an error earlier than later is a Good Thing, but an Even Better Thing would be to prevent crashing the backend, and afaics (as far as that is) the change you propose doesn't hurt anything. Do you see any way to do that? I'm glad to see work being done on domains. I'm definitely learning from the discussion. Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Fixing domain input
I'm glad to see work being done on domains. I'm definitely learning from the discussion. I wonder if we should implement 'GRANT USAGE ON DOMAINS' for spec compliance sometime... Chris ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Fixing domain input
Michael Glaesemann <[EMAIL PROTECTED]> writes: > Granted, finding an error earlier than later is a Good Thing, but an > Even Better Thing would be to prevent crashing the backend, and > afaics (as far as that is) the change you propose doesn't hurt > anything. Do you see any way to do that? For starters we'd have to forbid any user-written C functions. Somehow that doesn't seem like a net win. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Fixing domain input
On Apr 5, 2006, at 11:46 , Tom Lane wrote: For starters we'd have to forbid any user-written C functions. Somehow that doesn't seem like a net win. Ouch. Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Fixing domain input
I wrote: > 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. Currently trying to think of decent alternatives ... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
