Re: Domains versus polymorphic functions, redux

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

In response to

Responses

Browse pgsql-hackers by date

  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