On Wed, 2009-09-09 at 09:39 -0400, Tom Lane wrote: > Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
