| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Darren Duncan <darren(at)darrenduncan(dot)net> |
| Cc: | Florian Pflug <fgp(at)phlo(dot)org>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Range Types and extensions |
| Date: | 2011-06-20 18:58:21 |
| Message-ID: | 2176.1308596301@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Darren Duncan <darren(at)darrenduncan(dot)net> writes:
> I still think that the most elegant solution is for stuff like collation to just
> be built-in to the base types that the range is ranging over, meaning we have a
> separate text base type for each text collation, and the text operators are
> polymorphic over all those base types. Having collations and stuff as something
> off to the side not built-in to text/etc types is the root of the
> problem.
I tend to agree that this aspect of the SQL standard isn't terribly well
designed, but it's the standard and we're stuck with it. We're not
going to support two parallel methods of dealing with collations.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2011-06-20 19:00:43 | Re: [WIP] cache estimates, cache access cost |
| Previous Message | Greg Smith | 2011-06-20 18:46:44 | Re: [WIP] cache estimates, cache access cost |