Re: RfD: more powerful "any" types

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.)

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.)

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.)

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.

regards, tom lane