Kyle Bateman <kyle@actarg.com> writes:
> This function would load OK in 6.5 but doesn't work in 7.0beta1:
> create function date_week(date) returns text as '
> select date_week($1::text);
> ' LANGUAGE 'sql';
> ERROR: No such function 'date_week' with the specified attributes
> ... apparently, the parser does not recognize
> the fact that a cast is present and tries to look for an existing
> function date_week(date) instead of date_week(text).
Yup, 7.0beta1 is missing a couple of lines of code needed to handle
casts applied to function parameters. Thanks for catching that.
I have patched current CVS sources; tonight's snapshot should have
the fix.
> It looks like either there is a problem in the parser with casting, or
> there is a new way of doing things I should adapt to.
7.0 currently is a little snippier about casts than prior releases were;
it wants the cast to equate directly to an available conversion.
So what I'm getting from your example now is
regression=# create function date_week(date) returns text as '
regression'# select date_week($1::text);
regression'# ' LANGUAGE 'sql';
ERROR: Cannot cast type 'date' to 'text'
because there isn't a text(date) function. But there is a
text(timestamp) function, and a timestamp(date) function,
so this works:
regression=# create function date_week(date) returns text as '
regression'# select date_week($1::timestamp::text);
regression'# ' LANGUAGE 'sql';
CREATE
6.5 would do the intermediate conversion to timestamp (then called
datetime) silently, but 7.0 won't. Note that both versions will
happily take select date_week(text($1));
and interpolate the intermediate conversion step as part of resolving
the overloaded function name text(). 7.0 is only picky about
conversions written as casts.
I am not sure whether this should be regarded as a bug or a feature.
On the one hand you could argue that ambiguous casts are a bad thing,
but on the other hand, if text(foo) works, why shouldn't foo::text work?
One thing to realize while considering whether to change this is that if
we generalize the behavior of casts, we may also affect the behavior of
implicit casts, such as the one applied to convert supplied data in an
INSERT or UPDATE to the target column type. This could result in loss
of error detection capability. Currently, both 6.5 and 7.0 do this:
regression=# create table foo(f1 text);
CREATE
regression=# insert into foo values('now'::date);
ERROR: Attribute 'f1' is of type 'text' but expression is of type 'date' You will need to rewrite or cast the
expression
but if we allow datevalue::text to work, then (barring still more
pushups in the code) the above will be accepted. Should it be?
Comments anyone?
regards, tom lane
