The reason it is a bug rather than an unimplemented feature
is that it pokes a hole in the effectiveness of domains.
What good is a domain if it cannot be enforced everywhere
you use it? That is like having a hole in referential
integrity. (Though I admit not many people will run into
this until
Right. Sorry. My brain was over on parameter issues and
I did not reread my original bug...
On Fri, Feb 20, 2004 at 01:03:08PM -0500, Tom Lane wrote:
> elein <[EMAIL PROTECTED]> writes:
> > Shouldn't all function calls go (through fast path or fmgr
> > or the language manager?) to a centralized p
elein <[EMAIL PROTECTED]> writes:
> Shouldn't all function calls go (through fast path or fmgr
> or the language manager?) to a centralized parameter marshalling?
We're talking about what happens inside the function, not how you pass
parameters to it.
regards, tom lane
Robert Treat <[EMAIL PROTECTED]> writes:
> so ISTM that your example is certainly a deficiency if not a bug.
I believe it is a bug or at least an unimplemented feature in plpgsql:
plpgsql has its own implementation of casting, and is not aware that
casting to a domain should involve running check
plpgsql should be trying to coerce the return value to the functions return
type:
rms=# create or replace function retval(integer) returns text as ' begin
return $1::integer; end; ' language 'plpgsql';
CREATE FUNCTION
rms=# select retval(1) || ' is text';
?column?
---
1 is text
(1 row
I sent this a while ago to general and then
hackers and got no response.
The question is whether to qualify the return value
of a function when it returns a domain with
a check clause.
I believe it should--otherwise the domain is
only useful on insert and is not acting
like a full fledged type.
