Re: Domains versus polymorphic functions, redux - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: Domains versus polymorphic functions, redux
Date
Msg-id 6E6EF66C-F5E2-497F-A35B-69941E2FB1EC@kineticode.com
Whole thread Raw
In response to Re: Domains versus polymorphic functions, redux  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Domains versus polymorphic functions, redux  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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,
andsuperficially at least, the above will make it seem like more like than it does with the error. But maybe it's time
tore-think how domains are implemented? (Not for 9.1, mind.) I mean, why *don't* they act like first class types? 

Best,

David



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Alignment padding bytes in arrays vs the planner
Next
From: Tom Lane
Date:
Subject: Re: Alignment padding bytes in arrays vs the planner