My second problem with this proposal is that it simply ignores
the naming precedent of the existing polymorphic types. We have
a convention that polymorphic types are named "any-something",
and I do not think we should just toss that overboard. Moreover,
if we do end up needing "commonnonarray" or "commonenum", those
names are ugly, typo-prone, and unreasonably long.
the convention "any-something" is joined with just currently implemented families of polymorphic types. I propose new family, so I think so it should not be named "any-xxxx"
Maybe we can use some form of typemod - but typemod is ignored for function parameters - so it can be much more significant change
a alternative, probably very simple, but less power solution can be some special flag for function parameters - at the end, it is similar to previous solution.
I can imagine
create or replace function fx(p1 anyelement use_common_type, p2 anyelement, ...)
create or replace function fx2(p1 int, p2 int, variadic p3 anyarray use_common_type)
or maybe
create or replace function fx(p1 anyelement, p2 anyelement ...) ... language plpgsql options (use_common_type = true)
or we can drop it - on other thread you propose supported functions - can be some function, that can preproces parameters - and can replace polymorphic types by real types.
Comments, notes?
Pavel
