Re: BUG #5028: CASE returns ELSE value always when type is"char"

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #5028: CASE returns ELSE value always when type is"char"
Дата
Msg-id 10764.1251911947@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #5028: CASE returns ELSE value always when type is"char"  (Sam Mason <sam@samason.me.uk>)
Ответы Re: BUG #5028: CASE returns ELSE value always when type is"char"  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: BUG #5028: CASE returns ELSE value always when type is"char"  (Sam Mason <sam@samason.me.uk>)
Список pgsql-bugs
Sam Mason <sam@samason.me.uk> writes:
> ... For example:

>   CREATE FUNCTION add(int,int) RETURNS int LANGUAGE sql
>      AS $$ SELECT $1 + $2; $$;

>   CREATE FUNCTION add(int,int,int DEFAULT NULL) RETURNS text LANGUAGE sql
>     AS $$ SELECT ($1 + $2)::text; $$;

> What type should it attribute to the result of:

>   SELECT add(1,2);

> In fact it doesn't seem to want to play ball at all.  Even given the
> apparently unambiguous:

>   SELECT 1+add(1,2);
> or
>   SELECT 'hi'||add(1,2);

> It doesn't get anywhere.

Well, no, because our type resolution is bottom-up; it does not consider
context when trying to resolve the overloaded "add()" function
reference.  "Unknown" is the only part of the system that allows for any
delay at all in identifying the type of a construct, and even that is
limited to a literal and its first-level surrounding context.

It's interesting that you want to go in 100% the opposite direction from
Kevin, who seems to want to eliminate type inference altogether.  Maybe
our current compromise isn't too bad, if it makes everybody unhappy in
opposite directions ;-)

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #5025: Aggregate function with subquery in 8.3 and 8.4.
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: BUG #5028: CASE returns ELSE value always when type is"char"