From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Range Types, constructors, and the type system |
Date: | 2011-06-30 06:45:10 |
Message-ID: | CFF6B5E9-66D7-4E78-B580-8E98E5F632D7@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jun29, 2011, at 23:44 , Peter Eisentraut wrote:
> On ons, 2011-06-29 at 10:15 -0700, David E. Wheeler wrote:
>> On Jun 29, 2011, at 10:13 AM, Florian Pflug wrote:
>>> Because there might be more than one range type for a
>>> base type. Say there are two range types over text, one
>>> with collation 'de_DE' and one with collation 'en_US'.
>>> What would the type of
>>> range('foo', 'foooo')
>>> be?
>>
>> The one that corresponds to the current LC_COLLATE setting.
>
> Yes, or more generally, we have logic that determines, for example, what
> collation to use for
>
> 'foo' < 'foooo'
>
> The same logic can be used to determine what collation to use for
>
> range('foo', 'foooo')
>
> (In fact, if you implement range() as a user-space function, that will
> happen automatically.)
I don't think it will - as it stands, there isn't a single collatable
type RANGE but instead one *distinct* type per combination of base type,
btree opclass and collation. The reasons for that were discussed at length -
the basic argument for doing it that way was to make a range represent
a fixed set of values.
There's also no guarantee that a range type with collation LC_COLLATE
even exists.
best regards,
Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2011-06-30 06:51:43 | Re: Patch file questions? |
Previous Message | Jun Ishiduka | 2011-06-30 06:38:45 | Re: Online base backup from the hot-standby |