Re: polymorphic SQL functions has a problem with domains

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: polymorphic SQL functions has a problem with domains
Дата
Msg-id CAFj8pRBfA3xOvohFYZzNJ1rNCTu4_nmJk3SJqMuaAkyc+r+v3g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: polymorphic SQL functions has a problem with domains  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers



2014-04-02 17:19 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> I was informed about impossibility to use a polymorphic functions together
> with domain types

> see

>  create domain xx as numeric(15);

> create or replace function g(anyelement, anyelement)
> returns anyelement as
> $$  select $1 + $2 $$
> language sql immutable;

> postgres=# select g(1::xx, 2::xx);
> ERROR:  return type mismatch in function declared to return xx
> DETAIL:  Actual return type is numeric.
> CONTEXT:  SQL function "g" during inlining

That example doesn't say you can't use polymorphic functions with domains.
It says that this particular polymorphic function definition is wrong:
it is not making sure its result is of the expected data type.  I don't
recall right now whether SQL functions will apply an implicit cast on the
result for you, but even if they do, an upcast from numeric to some domain
over numeric wouldn't be implicit.

I though about this issue again, and I am thinking so it is PostgreSQL bug

we can do safe transformation from Parent type -> domain.

and returning result require same transformation (in this case) - so enforcing casting (not only binary casting) should be safe.

Otherwise - CAST(var AS var) should be useful and can helps too.

Regards

Pavel Stehule
 

                        regards, tom lane

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Including replication slot data in base backups
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: Get more from indices.