Re: RfD: more powerful "any" types

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: RfD: more powerful "any" types
Дата
Msg-id 29368.1252503589@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: RfD: more powerful "any" types  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: RfD: more powerful "any" types  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: RfD: more powerful "any" types  ("David E. Wheeler" <david@kineticode.com>)
Re: RfD: more powerful "any" types  (decibel <decibel@decibel.org>)
Re: RfD: more powerful "any" types  (Hannu Krosing <hannu@2ndQuadrant.com>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Well, so far we've only seen use cases in this thread that either
> already work or that are not well-defined. ;-)

Well, yeah, the question is can we extract a clear TODO item here.

I think there are two somewhat orthogonal issues:

1. Is a completely unconstrained argument type (ie "any") of any real
use to PL functions, and if so how can we expose that usefulness?
The only clear thing to do with such an argument is IS NULL/IS NOT NULL
tests, which might or might not be worth the trouble.

2. Is there any use for arguments with type constraints not covered
by the existing ANYFOO rules, and if so what do we add for that?

One comment on point 2 is that it was foreseen from the beginning
that there would be need for ANYELEMENT2 etc, and I'm actually rather
surprised that we've gone this long without adding them.  Alvaro made
a good point about not wanting to multiply the various hard-wired
OID references, but perhaps some judicious code refactoring could
prevent a notational disaster.
        regards, tom lane


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

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: COALESCE and NULLIF semantics
Следующее
От: Rafael Martinez
Дата:
Сообщение: More robust pg_hba.conf parsing/error logging