Re: RfD: more powerful "any" types
От | Hannu Krosing |
---|---|
Тема | Re: RfD: more powerful "any" types |
Дата | |
Msg-id | 1252527934.4080.16.camel@hvost1700 обсуждение исходный текст |
Ответ на | Re: RfD: more powerful "any" types (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: RfD: more powerful "any" types
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: