Re: RfD: more powerful "any" types

good analyse, thank you

2009/9/10 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 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,
>
> Yeah, that's exactly the problem.
>
> I am not sure that we really *have to* have a non-OID-based type
> representation though.  We have managed to have composite types without
> that, and I don't see why something similar would not work for
> functional types.
>
> But that's all well beyond the immediate problem, which is whether we
> need something more flexible than "anyelement".  ISTM we had these
> not-all-mutually-exclusive ideas on the table:
>
> 1. Allow the existing "any" pseudotype as an input argument type for PLs.
> (AFAICS this is simple and painless; about the only question is whether
> we want to keep using the name "any", which because of conflicting with
> a reserved word would always need the double quotes.)
>

I thing so this is possible - I see only one critical point - you
cannot validate source in validation time. You have to wait for run
time. This is some what we leave in plpgsql. I agree, so this is some
time one possible way for high level programming.

> 2. Come up with some way to do the equivalent of "variadic any[]",
> ie, a variable number of not-all-the-same-type arguments.  (This isn't
> just a type-system problem, there's also the question of how the type
> information would be passed at runtime.  IIRC we have a solution at the
> C level but not for PLs.)

again - this is possible, but there could be some strange cases -
because we have not polymorphic assign statement - and there are not
real some polymorphic variable type like variant or some similar (but
it not big problem to implement it). The bigger problem is cached plan
in assign statement, or other statements - minimally in plpgsql.

>
> 3. Add anyelement2/anyarray2, and maybe also -3 and -4 while at it.
>
> 4. Instead of #3, allow anyelement(N), which is certainly more flexible
> than #3 but would require a much larger investment of work.  (I'm
> uncertain whether attaching typmods to function arguments/results could
> have any interesting or unpleasant semantic side effects.  It might be
> all good, or maybe not.  It would definitely need some thought.)

anyelement(n) looks more general. I am not sure about readability.

>
> 5. Various syntactic sugar to substitute for anyelement.  (Not in favor
> of this myself, it seems to just complicate matters.)
>
> Functional types might be interesting in the long run but I don't see
> that they alter the need for one or more of these.
>

There could be some use cases like work-flow systems or maybe
scheduler event executor.

regards
Pavel Stehule

>                        regards, tom lane
>