From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, lr(at)pcorp(dot)us |
Subject: | Re: Domains versus polymorphic functions, redux |
Date: | 2011-05-24 18:17:59 |
Message-ID: | 6E6EF66C-F5E2-497F-A35B-69941E2FB1EC@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On May 24, 2011, at 10:11 AM, Tom Lane wrote:
> regression=# select negate(42::pos);
> ERROR: return type mismatch in function declared to return pos
> DETAIL: Actual return type is integer.
> CONTEXT: SQL function "negate" during inlining
>
> If we smashed to base type then this issue would go away.
+1
> On the other hand it feels like we'd be taking yet another step away
> from allowing domains to be usefully used in function declarations.
> I can't put my finger on any concrete consequence of that sort, since
> what we're talking about here is ANYELEMENT/ANYARRAY functions not
> functions declared to take domains --- but it sure seems like this
> would put domains even further away from the status of first-class
> citizenship in the type system.
I agree. It sure seems to me like DOMAINs should act exactly like any other type. I know that has improved over time, and superficially at least, the above will make it seem like more like than it does with the error. But maybe it's time to re-think how domains are implemented? (Not for 9.1, mind.) I mean, why *don't* they act like first class types?
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-05-24 18:18:28 | Re: Alignment padding bytes in arrays vs the planner |
Previous Message | Robert Haas | 2011-05-24 18:17:02 | Re: Alignment padding bytes in arrays vs the planner |