Re: RfD: more powerful "any" types
От | David E. Wheeler |
---|---|
Тема | Re: RfD: more powerful "any" types |
Дата | |
Msg-id | F32546DF-8093-40D7-AA63-440842C6620D@kineticode.com обсуждение исходный текст |
Ответ на | Re: RfD: more powerful "any" types (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: RfD: more powerful "any" types
|
Список | pgsql-hackers |
On Sep 9, 2009, at 6:39 AM, Tom Lane wrote: > 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. If you can pass an "any" to pg_typeof(), it's possible for functions to determine the types of arguments themselves and then to decide what to do with them (cast, etc.). I can see no reason not to give this ability to function authors, can you? > 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. The difference between allowing ANYELEMENT2, ANYELEMENT3, ANYELEMENT . ++$i and allowing "any" escapes me. Best, David
В списке pgsql-hackers по дате отправления: