| From: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Resolving polymorphic functions with relateddatatypes |
| Date: | 2008-07-03 17:42:56 |
| Message-ID: | 162867790807031042u7b7b6e76gb7b5a192e5137fac@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> What I'd be inclined to think about is making
> check_generic_type_consistency and related functions allow the
> arguments matched to ANYELEMENT to be of different actual types
> so long as select_common_type could determine a unique type to
> coerce them all to. It'd take some refactoring (notably, because
> select_common_type wants to throw error on failure, and because
> there'd have to be a way to pass back the type that was selected
> for use later).
+1
it's same like current implementation coalesce, least, greatest
functions, thats works well. And with this change and with variatic
functions we can move these functions from parser.
Regards
Pavel Stehule
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alex Hunsaker | 2008-07-03 17:53:59 | Re: Auto-explain patch |
| Previous Message | Garick Hamlin | 2008-07-03 17:36:28 | Solaris ident authentication using unix domain sockets |