Re: Another issue in default-values patch: defaults expanded too soon

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Another issue in default-values patch: defaults expanded too soon
Дата
Msg-id 18895.1229477957@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Another issue in default-values patch: defaults expanded too soon  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> So it's not like any use case for default polymorphic arguments is going to be
> especially compelling either. But I don't see any reason it'll be any less
> useful for polymorphic arguments than any other type.

Well, the reason it seems funny to me is that the point of a polymorphic
argument is to be datatype-agnostic, and as soon as you put in a default
value of a particular type you're letting go of that principle.

The only case I can imagine being actually useful is where the default
is an untyped null, and you have a non-defaultable anyelement argument
that drives determination of what the defaulted one is, ie something
like
create function array2 (f1 anyelement, f2 anyelement = null)returns anyarrayas 'select array[$1,$2]' language sql;

Although this seems well-defined in principle, I'm not sure if it
actually works with the current patch; and it'd be even trickier
if we try to put in some code that says "the default's type can't
change".  A null constant has the same type as an unmarked string
literal (namely UNKNOWN) but IIRC they don't really behave the same
for type resolution purposes.
        regards, tom lane


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: DTrace probes patch
Следующее
От: KaiGai Kohei
Дата:
Сообщение: Re: [BUG?] UPDATE with RETURNING tableoid