| From: | Florian Pflug <fgp(at)phlo(dot)org> |
|---|---|
| To: | David Fetter <david(at)fetter(dot)org> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Thom Brown <thom(at)linux(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Range Types - typo + NULL string constructor |
| Date: | 2011-10-11 13:20:05 |
| Message-ID: | 35BA2861-3B0D-49DD-ADFD-855B23E1D628@phlo.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Oct11, 2011, at 14:43 , David Fetter wrote:
> I'd recoil at not having ranges default to left-closed, right-open.
> The use case for that one is so compelling that I'm OK with making it
> the default from which deviations need to be specified.
The downside of that is that, as Tom pointed out upthread, we cannot
make [) the canonical representation of ranges. It'd require us to
increment the right boundary of a closed range, but that incremented
boundary might no longer be in the base type's domain.
So we'd end up with [) being the default for range construction,
but [] being the canonical representation, i.e. what you get back
when SELECTing a range (over a discrete base type).
Certainly not the end of the world, but is the convenience of being
able to write somerange(a, b) instead of somerange(a, b, '[)') really
worth it? I kind of doubt that...
best regards,
Florian Pflug
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-10-11 13:22:20 | Re: index-only scans |
| Previous Message | Pavel Stehule | 2011-10-11 13:18:33 | Re: Proposal: casts row to array and array to row |