Skip site navigation (1) Skip section navigation (2)

Re: Range Types, constructors, and the type system

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 (view raw or flat)
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


In response to

Responses

pgsql-hackers by date

Next:From: Florian PflugDate: 2011-06-30 06:51:43
Subject: Re: Patch file questions?
Previous:From: Jun IshidukaDate: 2011-06-30 06:38:45
Subject: Re: Online base backup from the hot-standby

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group