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'
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?
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 extens
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 o
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 ar
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
> rel
We've seen a couple of bug reports now about how domain constraints
aren't checked during input of a parameter that's been deduced to be
of a domain type, eg
http://archives.postgresql.org/pgsql-interfaces/2005-07/msg9.php
http://archives.postgresql.org/pgsql-bugs/2005-07/msg00084.php
There's a
