Re: RfD: more powerful "any" types

On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
> 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).

For functions, anonymous does not mean "impossible to identify" ;)

If it is something (semi)-permanent we should store it in pg_type and id
it by oid, if it is really, really transient (say a closure generated
upper in the function chain) we can probably assign it some kind of
temporary, per-process oid for the duration of its existence

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

here we still could reference this Type object by a 32 bit integer,
which points to either persistent or temporary "pg_type row"

The trick is to look up (typeid,typmod) pairs in some hashtable and not
generate duplicates.

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

we could also change parser and translate reserved word ANY to typename
"any" .

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

This will introduce some tricky situations, as we can't always do
function lookups in similar way to what we do now for real types.

An example:

f(a int, b text) and f(a text, b int)

are two different functions which can be distinguished by their
signature

so are

f(a int, b "any") and f(a "any", b int) and f(a "any", b "any")

but

f(a anyelement1, b anyelement2) and f(a anyelement2, b anyelement1)

seem to be different but actually are not, so we will need to handle
multiple anyelementN types separately from ordinary types.

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

agreed, it does not solve the underlying problem, just may make it
easier to understand and remember for users.

ANY [TYPE] and SAME AS [TYPE OF] are syntactic sugar indeed, but they
are much more SQL-like than needing to write "any" or anyelement(n) as
argument type or return type

--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training