Re: RfD: more powerful "any" types

2009/9/10 Robert Haas :
> On Wed, Sep 9, 2009 at 3:44 PM, Pavel Stehule  wrote:
>>> Really, I think we need a type system that doesn't try to represent
>>> every type as a 32-bit integer.  Right now, for example, there's no
>>> reasonable way to write a function that takes another function as an
>>> argument.  What we need is a system where base types are represented
>>> by an OID, but derived types (list and functional types) are built up
>>> using type constructors that take other types as arguments.  So you
>>> could have a types like list(integer) or list(anyelement) or
>>> function(integer,bool) [meaning either taking an integer and returning
>>> a bool, or the other way around, depending on your notational
>>> preference].  Then you can have functions with complex types like:
>>>
>>> maplist : function(anyelement,anyelement2,function(list(anyelement),list(anyelement2)))
>>>
>>> This would have the fringe benefit of eliminating types like anyarray
>>> (which is just list(anyelement)) and the need to list every type twice
>>> in pg_type, once for the base type and once for the derived array
>>> type.
>>
>> it would be nice, but probably it could significant increase parsing
>> query time. And this is +/- equal to what my transformationHook does.
>
> I can't believe that this is even close to being correct.
> Transformationhook is a cheap syntax hack (sorry, but it is).  It's
> not going to solve the problem of people who want anyelement and
> anyelement2, nor will it solve the problem of people who want to pass
> functions as arguments or treat them as first-class objects.

nobody written some better code. Just implement some too simple like
Oracle's decode function, and then talk about this topic. I like to
see this discus, but who looked on FuncnameGetCandidates functions,
and who knows, what is really possible.

regards
Pavel

>
> The major downside of such a system is that every place where we now
> count on being able to store a type in a fixed-size field would need
> to be touched.  I don't believe that the overall slowdown in parsing
> time would be significant, but I do think it would be a massive,
> highly invasive, highly destabilizing patch.  For the level of pain
> involved, there might be better uses of our time, which is not to say
> that I'd be in favor of rejecting such a patch out of hand if someone
> felt called to develop it (Tom might, though).
>
> ...Robert
>