Re: range bug in resolve_generic_type?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: range bug in resolve_generic_type?
Дата
Msg-id 12875.1566919412@sss.pgh.pa.us
обсуждение исходный текст
Ответ на range bug in resolve_generic_type?  (Paul A Jungwirth <pj@illuminatedcomputing.com>)
Ответы Re: range bug in resolve_generic_type?  (Paul A Jungwirth <pj@illuminatedcomputing.com>)
Список pgsql-hackers
Paul A Jungwirth <pj@illuminatedcomputing.com> writes:
> I was looking at resolve_generic_type to add anymultirange support,
> and the range logic doesn't seem correct to me.

Hmmm...

> resolve_generic_type(ANYARRAYOID, x, ANYRANGEOID) - this will return
> an array of the *range type*, but that contracts the normal
> relationship between anyelement and anyrange. It should return an
> array of the range's element type.

I seem to recall that we discussed this exact point during development
of the range feature, and concluded that this was the behavior we
wanted, ie, treat anyrange like a scalar for this purpose.  Otherwise
there isn't any way to use a polymorphic function to build an array
of ranges, and that seemed more useful than being able to build
an array of the range elements.  Jeff might remember more here.

> resolve_generic_type(ANYRANGEOID, x, ANYRANGEOID) - this will return
> the known range's *element* type, but it should return the known
> range.

Yeah, that seems like a flat-out bug.

> Fortunately we never call the function in either of those ways.

Wouldn't it depend on the signature+result type of the user-defined
function we're dealing with?  (That is, calls with constant argument
types are probably not the interesting ones.)

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: old_snapshot_threshold vs indexes
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: Re: pgbench - implement strict TPC-B benchmark