Re: Range Types, constructors, and the type system

On Tue, Jun 28, 2011 at 12:58 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> On Tue, 2011-06-28 at 10:58 -0400, Robert Haas wrote:
>> On Mon, Jun 27, 2011 at 11:42 PM, Jeff Davis <pgsql@j-davis.com> wrote:
>> > So, in effect, RANGEINPUT is a special type used only for range
>> > constructors. If someone tried to output it, it would throw an
>> > exception, and we'd even have enough information at that point to print
>> > a nice error message with a hint.
>>
>> I don't think I like the idea of throwing an error when you try to
>> output it, but the rest seems reasonably sensible.
>
> I thought it might add a little confusion if people thought they had a
> range type but really had RANGEINPUT. For instance, if you do a "create
> table as select range(1,2)" then the result might be slightly
> unexpected.

True...

> But it's probably no more unexpected than "create table as select
> 'foo'". So, I suppose there's not much reason to throw an error. We can
> just output it in the same format as a range type.

+1.

> It's also much easier to explain something in the documentation that has
> an output format, because at least it's tangible.

+1.

>> > Actually, this is pretty much exactly Florian's idea (thanks again,
>> > Florian), but at the time I didn't like it because "pair" didn't capture
>> > everything that I wanted to capture, like infinite bounds, etc. But
>> > there's no reason that it can't, and your point made me realize that --
>> > you are effectively just using TEXT as the intermediate type (which
>> > works, but has some undesirable characteristics).
>>
>> What undesirable characteristics?
>
> Well, for one, outputting something as text and then reading it back in
> does not always produce the same value. For instance, for float, it only
> does that if you have extra_float_digits set to some high-enough value.
> I suppose I could save the GUC, set it, and set it back; but that seems
> like unnecessary ugliness.

Yeah, I don't think we want to go there.

> There's also the deparsing/reparsing cycle. That might not really matter
> for performance, but it seems unnecessary.
>
> And there's always the fallback that "we have types for a reason".
> Wouldn't it be odd if you wrote a query like:
>  select range(1,2) || 'foo'
> and it succeeded? I'm sure that kind of thing can lead to some dangerous
> situations.

That's pretty much what we tried to get rid of with the 8.3 casting
changes, so agreed.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company