| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Florian Pflug <fgp(at)phlo(dot)org> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Darren Duncan <darren(at)darrenduncan(dot)net> |
| Subject: | Re: Range Types and extensions |
| Date: | 2011-06-18 22:23:00 |
| Message-ID: | 1308435780.2597.68.camel@jdavis |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, 2011-06-18 at 22:19 +0200, Florian Pflug wrote:
> Yes, that seems necessary for consistency. That leaves the question
> of what to do if someone tries to modify a textrange's collation with
> a COLLATE clause. For example,
>
> For example, whats the result of
> 'Ä' in '[A,Z']::textrange_german COLLATE 'C'
> where 'Ä' is a german Umlaut-A which sorts after 'A' but before 'B'
> in locale 'de_DE' but sorts after 'Z' in locale 'C'. (I'm assuming
> that textrange_german was defined with collation 'de_DE').
>
> With the set-based definition of ranges, the only sensible thing
> is to simply ignore the COLLATE clause I think.
I think rejecting it makes more sense, so a range would not be a
collatable type; it just happens to use collations of the subtype
internally.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steve Singer | 2011-06-18 22:36:05 | Re: patch for 9.2: enhanced errors |
| Previous Message | Peter Eisentraut | 2011-06-18 22:18:50 | pgsql: Make external_pid_file world readable |