Re: Range type adaptation implemented
От | Jonathan S. Katz |
---|---|
Тема | Re: Range type adaptation implemented |
Дата | |
Msg-id | 762C37E3-19FE-4462-B690-EFBE6ECAF29A@excoventures.com обсуждение исходный текст |
Ответ на | Re: Range type adaptation implemented (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Ответы |
Re: Range type adaptation implemented
|
Список | psycopg |
On Sep 24, 2012, at 5:57 AM, Daniele Varrazzo wrote:
On Mon, Sep 24, 2012 at 10:45 AM, Karsten Hilbert
<Karsten.Hilbert@gmx.net> wrote:On Mon, Sep 24, 2012 at 09:56:14AM +0100, Daniele Varrazzo wrote:The funniest surprise I've had during the developmentwas an error creating the object TextRange('#', '$') in the database.It should be possible asord('#'), ord('$')(35, 36)but PG insisted that "range lower bound must be less than or equal torange upper bound". Well, turns out that:postgres=# select ascii('#') < ascii('$'), '#' < '$';?column? | ?column?----------+----------t | f(1 row)This does not seem intuitive but is probably quite logical:Whileascii('#') < ascii('$')eventually compares numerical values (35 and 36) the comparison'#' < '$'operates on characters the sorting order (<) of whichdepends on the lcoale in use.
That's right: the reason is the locale. select '#' collate "C" < '$'
collate "C" returns true as naively expected.
-- Daniele
With that said, referencing this line:
Because those sets of operators are supposed on the Postgres side, perhaps we could provide an error message indicating that? That way if someone needs to look at the comparisons between ranges they know the database operators. So maybe:
"Range objects cannot be ordered - please refer to the PostgreSQL documentation to perform this operation in the database"
Jonathan
В списке psycopg по дате отправления: