Re: RfD: more powerful "any" types

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RfD: more powerful "any" types
Date: 2009-09-09 16:37:07
Message-ID: F32546DF-8093-40D7-AA63-440842C6620D@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message decibel 2009-09-09 16:41:38 Re: RfD: more powerful "any" types
Previous Message decibel 2009-09-09 16:30:35 Re: Elementary dependency look-up