Re: proposal: new polymorphic types - commontype and commontypearray
От | Pavel Stehule |
---|---|
Тема | Re: proposal: new polymorphic types - commontype and commontypearray |
Дата | |
Msg-id | CAFj8pRAvVgwd5iaZE2aNHxtPssE0qdMdr9LsDRRqiEw-xS_73A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: new polymorphic types - commontype and commontypearray (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: