Re: RfD: more powerful "any" types

On Thu, Sep 10, 2009 at 2:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

It might be possible to make it work, but it's likely to create a lot
of bloat in pg_type, and will make it very difficult to implement
features such as anonymous functions (i.e. LAMBDA). I think it's
further embedding a not-particularly-great design decision. We've
already patched around the insufficiency of representing types as
32-bit integers for types by adding typmods, but that solution is
incompletely implemented (as exemplified by your comments below under
#4, and I don't think that's the only example) and doesn't handle all
the interesting cases. Maybe we should move in the direction of
having some kind of semi-opaque Type object that for now can contain a
typid and typmod, and always compare types by using some abstract
function that operates on 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.)

+1 from me. I could go either way on changing the name, but if we're
to do it, first we'll have to think of something better than "any",
which might not be so easy.

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

This also seems like a good idea. Will pg_typeof() work for PL/pgsql?
I think if we can come up with a solution for PL/pgsql, it would be
reasonable to commit this, leaving the tidying up for any PLs for
which the right solution is non-obvious to someone who wants the
feature enough to propose an appropriate patch.

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

Of these two, I prefer #4, but I don't think #3 would be horrible either.

> 5. Various syntactic sugar to substitute for anyelement.  (Not in favor
> of this myself, it seems to just complicate matters.)

I agree; I don't think this solves any real problem.

...Robert