On Wed, Sep 9, 2009 at 3:44 PM, Pavel Stehule <pavel.stehule@gmail.com> 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.
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
