> > > >> 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 > regards, tom lane >> >
