From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Range Types, constructors, and the type system |
Date: | 2011-07-05 15:48:58 |
Message-ID: | 1FE22405-4DBA-408A-A785-31C405F36F54@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jul5, 2011, at 17:11 , Jeff Davis wrote:
> I'm OK with the intermediate type, but Florian seems skeptical of that
> idea.
I'm starting to get used to it, though ;-) I do now believe that it can
be made safe against accidental miss-use, it seem that I was overly
anxious there.
What I still don't like about it is that it feels like a workaround for
a feature missing in our type system - the possibility of having function
with a polymorphic return type, but no polymorphic arguments. I feel
somewhat strongly about this, because it bit me when I tried to implement
record_getfield() and record_setfield() to get and set a record's field
based on it's name.
However, placing the burden of solving that onto the range type patch
doesn't seem fair.
Plus, I've realized now that a RANGEINPUT type would allow us to easily
support some things that otherwise seem hard. We could, for example,
make the cast from RANGEINPUT to the individual range types an assignment
cast (or even implicit), thereby removing the need for an explicit
cast in a lot of common cases like insert into a table with a range column.
best regards,
Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-07-05 15:49:48 | capturing regression test core dump |
Previous Message | Kohei Kaigai | 2011-07-05 15:46:06 | Re: [v9.2] SECURITY LABEL on shared database object |