On Wed, 2009-09-09 at 09:39 -0400, Tom Lane wrote:
> 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.
Where we could need anyelement2 and enyelement3 is if we need the
sameness of any 2 parameters or OUT parameter types
maybe we could (re/ab)use parametrized types and define
anyelement(1), anyelement(2), ..., anyelement(N) and then match them by
the number in parentheses
> 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
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability Services, Consulting and Training
