From: | "Sven R(dot) Kunze" <srkunze(at)mail(dot)de> |
---|---|
To: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: ERROR: functions in index expression must be marked IMMUTABLE |
Date: | 2017-03-03 11:44:27 |
Message-ID: | 4e4d464d-efa7-f004-4070-31457dfead7e@mail.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 03.03.2017 11:43, Geoff Winkless wrote:
> One alternative would be to make to_date accept all language variants
> of months simultaneously. A quick search of google suggests that there
> aren't any overlaps between languages (ie where one language uses
> "Foo" for March and another uses "Foo" for May), although you would
> have to do some more intense research to be sure. As far as I can see
> there's no other reason why to_date would need to be marked as
> stable/volatile, is there?
I don't think so. It could be viable.
> On the down side I imagine it would involve some
> potentially-prohibitively-large lookup tables; it would also end up
> with a technical incompatibility in that what ANSI SQL would reject as
> not-a-date might be parsed as a date.
There is another issue: languages change (admittedly very slowly) but I
wouldn't want PostgreSQL to be incompatible with future generations.
Your performance argument weighs heavier, though.
> I'm not in a position to judge if either of those would be acceptable.
Do you think I should post to pgsql-hackers?
Sven
From | Date | Subject | |
---|---|---|---|
Next Message | Rui Pacheco | 2017-03-03 11:51:44 | PortalSuspended |
Previous Message | Geoff Winkless | 2017-03-03 10:43:32 | Re: ERROR: functions in index expression must be marked IMMUTABLE |