Re: Patch for 8.5, transformationHook

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Patch for 8.5, transformationHook
Дата
Msg-id 23328.1249933425@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Patch for 8.5, transformationHook  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: Patch for 8.5, transformationHook  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Patch for 8.5, transformationHook  (Sam Mason <sam@samason.me.uk>)
Список pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote: 
>> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>>> Still, it rates pretty high on my astonishment scale that a
>>> COALESCE of two untyped NULLs (or for that matter, any two values
>>> of unknown type) returns a text value.
>> 
>> What would you have it do instead, throw an error?
> Return a value of unknown type.
That would require doing actual computation on values of unknown type.

In the specific case of COALESCE, we could theoretically do that,
since the only computation it needs is "IS NULL" which is
datatype-independent.  In most situations, however, you can't evaluate
the function without knowledge of the datatype semantics.  As an
example, consider NULLIF('0', '00').  This gives different answers if
you suppose the literals are text than if you suppose they are integers.

So yeah, we could make COALESCE into a special-case wart in the type
system and have it able to execute without inferring a type for the
arguments.  I don't think that would be a net improvement in the
system's astonishment quotient, however; people would just be confused
why COALESCE behaves differently from everything else.
        regards, tom lane


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

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Patch for 8.5, transformationHook
Следующее
От: Alexey Klyukin
Дата:
Сообщение: Re: PL/Perl crash when using threaded perl